CC BY
42
НАУКОЕМКИЕ ТЕХНОЛОГИИ В КОСМИЧЕСКИХ ИССЛЕДОВАНИЯХ ЗЕМЛИ, Т
№ 4-2019
'АДИОТЕХНИКА И СВЯЗЬ
//
doi: 10.24411/2409-5419-2018-10276
САМОДИАГНОСТИКА КАК ОСНОВА ПОСТРОЕНИЯ СИСТЕМ СЕТЕВОГО ТЕХНОЛОГИЧЕСКОГО УПРАВЛЕНИЯ ОБОРУДОВАНИЕМ СИСТЕМ СВЯЗИ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ
ВЕРЕЩАГИНА Елена Валентиновна1
ТОЛСТИХИН Александр Игоревич2
НЕВЕРОВ
Александр Павлович3
Сведения об авторах:
1инженер открытого акционерного общества «СУПЕРТЕЛ», г. Санкт-Петербург, Россия, vereshagev@mail.ru
2инженер открытого акционерного общества «СУПЕРТЕЛ», г. Санкт-Петербург, Россия, tolstihin91@mail.ru
АННОТАЦИЯ
Сформулированы общие принципы создания эффективно работающей системы управления сложных организационно-технических систем, например систем связи. Рассмотрены варианты построения системы сетевого технологического управления оборудованием связи систем связи специального назначения, в частности систем связи с шифрованием данных в канале технологического управления. Приведено описание и требования к программному обеспечению верхнего и нижнего уровней. Обоснована необходимость «модульного» принципа построения программного обеспечения. Описаны взаимосвязи между модулями программного обеспечения и функционирование программного обеспечения по иерархиям управления при сбое в функционировании отдельных модулей программного обеспечения или при возникновении аварийных ситуаций на сети связи и/или в канале сетевого технологического управления. Представлено обоснование необходимости реализации функций телеметрии и мониторинга состояния отдельных модулей программного обеспечения и всей системы сетевого технологического управления. Обоснована система защиты и безопасности функционирования системы сетевого технологического управления с шифрованием в канале технологического управления. Предложено иметь средства долговременной фиксации и учёта событий в аппаратуре для их восстановления и корректной работы системы сетевого технологического управления после восстановления связи с оборудованием. Представлены и описаны методы разграничения прав пользователей в системе технологического управления оборудованием систем связи. Описана процедура верификации управления оборудованием.
3начальник отдела федерального государственного бюджетного учреждения «МИР ИТ», г. Москва, Россия, apnewerov@mail.ru
КЛЮЧЕВЫЕ СЛОВА: система (сеть) связи; канал управления; телеметрия; система сетевого технологического управления; мониторинг.
Для цитирования: Верещагина Е.В., Толстихин А.И., Неверов А.П. Основные направления развития метеорной связи // Наукоемкие технологии в космических исследованиях Земли. 2019. Т. 11. № 4. С. 22-28. doi: 10.24411/2409-5419-2018-10276
В качестве систем связи специального назначения рассмотрим системы с шифрованием канала сетевого технологического управления. Система связи с шифрованием канала сетевого технологического управления является подсистемой доставки сообщений в системе военной связи [1]. Возьмем в качестве объекта рассмотрения систему связи с шифрованием канала сетевого технологического управления, включающую мультиплексор (управляемый объект), персональный компьютер с установленной программой сетевого управления (управляющий объект), а так же интерфейс между ними [2]. Управление осуществляет оператор (оператор системы управления).
Системы связи специального назначения с шифрованием канала сетевого технологического управления является автоматизированной системой и обладают следующей спецификой (ГОСТ 34.003-90):
- сложность (большое количество различных подсистем сложно связанных между собой),
- высокая вероятность возникновения нештатных ситуаций (чем сложнее система, тем вероятнее нештатные ситуации),
- перегруженность системы управления различной информацией,
- использование шифрования данных и шифрования канала управления [3].
Следовательно, существует необходимость:
- предупреждения нештатных ситуаций (закладывается на этапе проектирования),
- обеспечения на этапе разработки средств тестирования и верификации системы управления; связи, обеспечивающие слаженную работу системы связи специального назначения закладываться, начиная с первоначального этапа проектирования аппаратуры.
Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», выделяют следующие основные стадии создания и этапы разработки автоматизированной системы: формирование требований к автоматизированной системе, разработка концепции автоматизированной системы, техническое задание, технический проект, рабочая документация, ввод в действие, сопровождение автоматизированной системы.
На стадии технического проекта определяется функциональная и техническая архитектура, исходя из которых на этапе рабочей конструкторской документации осуществляется разработка программ.
Согласно ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология», процессы жизненного цикла программных средств, процесс разработки программных средств включает: процесс состоит из следующих работ: подготовка процесса, анализ требований к системе, проектирование системной архитектуры, анализ требований к программным средствам, проектирование программной
¿ZK—.....
Vol 11 No 4-2019, H&ES RESEARC-RF TECHNOLOGY AND COMMUNICATION
архитектуры, техническое проектирование программных средств. Далее: программирование и тестирование, а так же сборку программных средств.
На данном этапе осуществляется декомпозиция требований к программному обеспечению на язык частных задач. Декомпозиция представляет собой разложение этих требований на реализуемые программным обеспечением функции. Описанные функции так же подвергаются декомпозиции и, в итоге, всё программное обеспечение разделяется на элементарные неделимые модули кода.
Модуль — фрагмент программного текста, являющийся строительным блоком для физической структуры системы (программного обеспечения).
Модульность — свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей [4].
Мультиплексор имеет блочную структуру, каждый блок выполняет специфические функции. Для удобства, программное обеспечение блоков строится иерархически, с соблюдением принципов построения, общих для каждого блока, по возможности, из универсальных модулей.
При этом, понятие «неделимости» модулей носит условный характер, модули выполняют функции, свойственные всем или большинству блоков устройства, то есть, во-первых, относительно универсальны, во-вторых, модули, элементарны условно, так как дальнейшее деление возможно, но будет избыточным. Таким образом, разделение программного обеспечения на элементарные модули целесообразно проводить до тех пор, пока модули не станут максимально универсальными, при этом, не теряя разумной функциональности. Глубину подобного рода деления определяют в каждом конкретном случае.
Работы по проектированию программной архитектуры процесса разработки программного обеспечения заканчиваются формализацией задач для элементарных модулей, из которых, впоследствии, будет «построен» весь «код» устройства [5]. Код выстраивается по принципу иерархичности. Каждый модуль кода более высокого уровня сложности, выполняет функции, используя выходные данные одного или нескольких элементарных модулей (однотипных или разнотипных), принадлежащих предыдущему уровню сложности.
При использовании описанной иерархической организации программного обеспечения следует учитывать, что модуль состоит из интерфейсной части и части реализации [4]. Начиная от следующего за самым элементарным уровня, каждый модуль программного обеспечения является зависимым от сигналов на интерфейсах модуля/модулей предыдущего уровня. Непоступление данных, либо поступление некорректных данных от внутреннего модуля может привести внешний модуль программного обеспечения к «зависанию». Для решения проблемы каждый внешний
х>>\ \\\\
НАУКОЕМКИЕ ТЕХНОЛОГИИ В КОСМИЧЕСКИХ ИССЛЕДОВАНИЯХ ЗЕМЛИ, Т АДИОТЕХНИКА И СВЯЗЬ
№ 4-2019
модуль должен быть снабжен системой защиты от такого рода событий — сигналами телеметрии и самосброса. Телеметрию можно рассматривать как область электроники, охватывающую системы измерения каких-либо параметров объектов без непосредственного участия человека.
Построение иерархии модулей программного обеспечения необходимо организовать таким образом, чтобы исключить блокировку работы внешнего, по уровню, модуля, в случае нештатной ситуации внутреннего (внутренних). На случай отказа модуля должен быть реализован механизм сброса внутреннего модуля, либо игнорирования его сбоя, а так же, по возможности, сигнал телеметрии, идентифицирующий:
- некорректно отрабатывающий модуль,
- причину сбоя в модуле.
Для каждого модуля программного обеспечения должна быть предусмотрена система ожидания для каждого сигнала, от которого зависит работа данного модуля программного обеспечения, система ожидания состоит из таймеров, отсчитывающих предельное время ожидания сигнала. После истечения данного времени, модуль должен продолжить работу в аварийном режиме, игнорируя неполученные сигналы и сообщив об аварии модулю верхнего уровня.
Сигналы, позволяющие программному обеспечению управляемого объекта работать, невзирая на некорректную работу его частей, обеспечивают безотказность работы управляемого объекта [6], а сигналы, идентифицирующие причину и модуль сбоя, будучи выведены на самый «внешний» уровень, обеспечат максимально подробный мониторинг состояния управляемого объекта.
Из вышеописанного следует, что, в процессе разработки программного обеспечения следует снабдить всю иерархическую структуру программного обеспечения средствами телеметрии, которые охватывают все модули программного обеспечения от самого элементарного (внутреннего) до внешнего уровня. На внешнем уровне реализовать получение «слова» (данных) состояния, полностью описывающего состояние каждого модуля программного обеспечения.
Программное обеспечение, состоящее из элементарных модулей, реализует функции системы связи. Функции классифицируются на:
- непосредственные — непосредственно реализующие назначение устройства, например для шифратора — это функции шифрования данных;
- обеспечительные — передача данных между аппаратными модулями, опрос систем аппаратуры на предмет готовности к работе, инициализация систем;
- надежности — дубляж передачи, запросы подтверждения, проверка контрольных сумм;
- самодиагностики — получение и вывод информации о сбоях и нештатных ситуациях, а так же состоянии модулей программного обеспечения;
- управления/мониторинга — приём от оператора настроечных данных их передача соответствующей подсистеме (управление) и выполнение действий, в ответ на полученные настроечные данные (выполнение); кроме того, осуществляется посылка сигналов оборудования, разделяющихся на сигналы, считываемые внешней системой управления, и сигналы, посылаемые оборудованием без запросов внешней системы;
- верификации управления — относительно новое понятие; система, заложенная в программное обеспечение, позволяет в дальнейшем имитировать события оборудования, посредством простых внешних воздействий (например, ввод значений через консоль); это даёт возможность тестирования работы оборудования, как для улучшения свойств удобства, так и для выявления ошибок, при изменении программного обеспечения;
- безопасности—техническая и организационная; организационная должна выполнять функции, которые нельзя возложить на техническую (автоматическую) систему.
В общем случае, система безопасности выполняет две функции:
- недопущение вторжений;
- уничтожение информации, подвергшейся воздействию.
В системах связи специального назначения с шифрованием канала управления в функции безопасности входит функция сокрытия данных, передаваемых по каналу управления, и самого факта передачи данных.
Система связи специального назначения с шифрованием канала управления подвержена повышенному риску разрыва связи по управлению. Следовательно, предусматриваются возможности долговременной фиксации и учёта событий в аппаратуре, данные о которых могут быть считаны после восстановления связи.
Кроме того, сигналы самодиагностики, встроенные в модули, из которых состоят части программного обеспечения, реализующие различные функции системы связи, классифицируются на:
- сигналы самосброса и самодиагностики;
- сигналы подтверждения управления;
- сигналы, извещающие о выполнении функций;
- сигналы имитации событий.
Сетевая система управления, установленная на внешнем терминале, имеет аналогичные средства самодиагностики:
- сигналы журналирования в энергонезависимой памяти и считывания оттуда;
- сигналы обеспечения актуальности данных;
¿¿к
и /У//
4-2019, Н&ББ РЕББАРС
- сигналы максимально наглядного и структурированного отображения данных;
- сигналы оповещения об изменении данных;
- подсистему интерактивной помощи, минимизирующую информацию, первоначально выводимую на экран и обеспечивающую возможность получить исчерпывающую информацию и инструкции при наступлении любого события.
Система сетевого технологического управления, в сочетании с системами самодиагностики, встроенными в каждую подсистему программного обеспечения объекта управления формирует определенный (достаточно объёмный) массив данных, обеспечиваемых датчиками [7, с. 9], которые делятся на функциональные и датчики самодиагностики. Функциональные датчики информируют о работе определенной функции аппаратуры, датчики самодиагностики показывают работу самого программного обеспечения.
Программное обеспечение мультиплексора взаимодействует с программным обеспечением системы сетевого технологического управления, установленной на объекте управления (персональном компьютере). Программное обеспечение системы сетевого технологического управления считывает данные с датчиков из регистров мониторинга, и записывает сигналы управления в регистры управления. Управляемость системы связи специального назначения [8] зависит от аспектов, рассмотренных ниже.
Актуальность данных. Требуемая степень актуальности достигается периодичностью опроса датчиков оборудования. Частота периодических опросов определяется на основе статистических расчётов по данным о возможной частоте смены состояний аппаратуры, требований ко времени реакции системы сетевого управления на изменение указанных состояний.
Полученные значения функциональных датчиков должны быть максимально оперативно отображены в системе управления.
Датчики самодиагностики, зачастую, не представляют интереса для оператора и должны отображаться в системе управления таким образом, чтобы информировать оператора о внештатных ситуациях оборудования, при этом подробные сведения датчиков следует заносить в журнал учёта состояний в оборудовании — технологический журнал (отдельная область памяти, содержащая сведения об авариях/ предавариях и ошибках). Технологический журнал должен быть доступен для считывания квалифицированным администратором, защищен от потери данных при отключении электропитания (находиться в энергонезависимой памяти) и содержать максимально подробную информацию. Данный вид журнала реализует следующие функции:
- подробный учёт состояний («логирование») устройства без ущерба для наглядности информации
Уо! 11 N
РР ТЕСНКЮЮСУ дт соммим
мониторинга в системе управления для штатной работы оператора;
- дублирование данных мониторинга для случаев разрыва связи по управлению;
- аккумулирование (сбор статистики) данных об ошибках оборудования для верификации и улучшения эксплуатационных свойств оборудования.
Любая система управления, в том числе система сетевого технологического управления оборудованием связи, должна быть построена как система с обратной связью [8], поэтому на все управляющие воздействия управляемые объекты должны формировать:
- ответные сигналы оборудования, подтверждающие получение управляющего воздействия,
- сигналы оборудования об изменении характеристик вследствие управляющего воздействия (численные значения, показатели изменения состояний, режимов работы, настроек и др.).
Наиболее эффективной является система [1, 8], в которой каждое управляющее воздействие, во-первых, подтверждается оборудованием в части получения, во-вторых подтверждается сигналами об успешном изменении состояния оборудования.
Одним из основных требований является то, что в системе сетевого технологического управления данные состояния управляемой системы связи должны отображаться максимально полно и однозначно информационно для оператора.
Не существует формализованной методики (рекомендаций) отображения данных, позволяющей однозначно достичь удобства для всех требований пользователя. Поэтому визуализация данных мониторинга, состояния отдельного оборудования связи и данных о всей системе (сети) связи и удобство ведения диалога «человек — машина», очевидно, может быть достигнуто опытным путем в процессе верификации по требованиям и рекомендациям, выявляемым в процессе эксплуатации.
При проектировании и на практике следует учитывать правило «трех кликов», предъявляемое к интернет ресурсам, предписывающее строить любое меню таким образом, чтобы до любого места можно было «добраться», сделав не более трёх кликов [9-13]. Таким образом, не стоит углублять уровень вложенности меню программного обеспечения управляющей подсистемы.
Следует отметить, что только визуализации данных мониторинга недостаточно, так как такая информация доступна только при взгляде на монитор а, пользователь (оператор) должен иметь доступ ко всей информации, позволяющей качественно и количественно оценить состояние объекта в любой момент времени функционирования системы связи [7, с. 11]. При наступлении событий, на ко-
НАУКОЕМКИЕ ТЕХНОЛОГИИ В КОСМИЧЕСКИХ ИССЛЕДОВАНИЯХ ЗЕМЛИ, Т 11 № 4-2019
РАДИОТЕХНИКА И СВЯЗЬ
торые необходима реакция оператора, данные мониторинга должны быть сопровождены звуковыми оповещениями. Современные пользователи часто выдвигают требования к голосовым оповещениям, однозначно указывающим на наступление события, конкретизирующим его название, хотя такого рода оповещения должны иметь возможность отключения на время пусконаладочных, регламентных и ремонтных работ.
Относительным новшеством является технология «интерактивной помощи». В аппаратуре специального назначения имеются специфические характеристики и, следовательно, датчики, в названии которых не представляется возможным привести исчерпывающую информацию о наступившем событии.
Система интерактивной помощи позволяет, при нажатии на краткую информацию о наступлении события, получить необходимые разъяснения.
Разъяснения должны быть доступны посредством навигации по видеокадрам по принципу «от общего к частному» и наоборот с помощью меню и/или объектов экранной формы [7, с. 16] и содержать:
- точное и подробное название события, включающее номер блока, порта, канала, пакета и другое;
- параметры события (критичность, время, место, свойства — авария на дальнем/ближнем конце тракта);
- возможные причины возникновения события;
- рекомендуемые действия при наступлении события для всех категорий персонала, с возможностью их совершения прямо из соответствующего меню (вызов администратора, удостоверение записи в журнале, изменение настроек, диагностика).
Защищенность данных системы сетевого технологического управления должна обеспечивать подтверждение и невозможность случайного ввода управляющего воздействия. Кнопки, переключатели и прочие инструменты системы управления, принимающие от оператора команды управления аппаратурой должны обладать следующими свойствами:
- невозможность случайного ввода некорректных значений (переключатели с заданными значениями), блокировка инструментов недоступных данной категории пользователей,
- подтверждение ввода (дублирование), комбинирование ввода посредством клавиатуры и мыши, вывод запроса на подтверждение действия.
Контроль доступа к системе сетевого технологического управления подразделяется на аутентификацию пользователей и учёт действий каждого пользователя, а контроль целостности файлов системы сетевого технологического управления реализуется настройкой операционной системы персонального компьютера, являющегося терминалом системы управления.
Применяется метод разграничения прав пользователей персонального компьютера. Пользователь с административными правами подтверждает свои полномочия при помощи организационных мер. При этом он не имеет прав на запуск программного обеспечения системы сетевого технологического управления (не имеет данных учётной записи в системе управления), но на уровне операционной системы имеет права администрирования (обновление программного обеспечения и подобное).
Пользователи, обладающие правами работы с системой сетевого технологического управления имеют права и возможности (достигается соответствующей настройкой операционной системы) исключительно запуска и работы в системе технологического управления оборудованием сети связи.
Удобство, эффективность, наглядность системы сетевого технологического управления достигаются путем верификации. Для целей верификации вводится дополнительная система, логически находящаяся между аппаратурой и системой управления. Идеальным вариантом является возможность имитации всех событий оборудования и фиксации их корректного и наглядного отображения в системе управления. Однако в системах специального назначения с шифрованием, шифрованием канала управления, события делятся на имитируемые и неимитируе-мые. В случае датчиков разрыва соединения и тому подобное, управлять наступлением события вполне возможно (отключение соответствующих кабелей связи от оборудования), в случаях специфических ошибок шифрования — практически невозможно. Для решения проблемы в систему должна встраиваться возможность имитации всех событий путем ввода (например, при помощи консоли) значений ошибок (событий) уже в сами «слова» состояния (регистры), считываемые системой сетевого управления, как информация датчиков.
Для этого предлагается следующее решение: датчики оборудования собираются в регистры мониторинга, данные из которых считывает сетевая система технологического управления. Физически, регистры каждого блока объекта управления (мультиплексора) находятся на верхнем уровне иерархии программного обеспечения данного блока. Для каждого регистра мониторинга создают регистр имитации, доступный на запись при помощи, к примеру, персонального компьютера через консоль (могут использоваться иные решения). Данные имитационных регистров складываются по «ИЛИ» с данными регистров блока. Данные регистров блока считываются сетевой системой технологического управления. Такая возможность должна закладываться в процессе проектирования связей программного обеспечения мультиплексора.
При любом изменении, как программного обеспечения аппаратуры, так и программного обеспечения сетевой
системы технологического управления, необходимо проводить несколько последовательных серий имитаций всех событий и фиксировать выводы о корректности, удобстве и возможностях улучшения управляемости устройства.
Системы самодиагностики (телеметрии, ожидания, сброса), заложенные на этапе проектирования и встроенные на этапе создания во все подсистемы аппаратуры, позволяют выйти на новый уровень производства аппаратуры, иметь возможность верификации любой системы аппаратуры, на всех этапах её жизненного цикла.
Литература
1. Ермишян А. Г. Теоретические основы построения систем военной связи в объединениях и соединениях. Часть 1. Методологические основы построения организационно-технических систем военной связи. СПб.: Изд-во ВАС, 2005. 740 с.
2. Теория управления: Терминология / Отв. ред. Б. Г. Волик. М.: Наука, 1988. 262 с.
3. СонькинМ. А., Яммпольский В. З. Обобщенные свойства специальных систем связи и мониторинга для труднодоступных и подвижных объектов // Известия Томского политехнического университета. 2008. Т. 312. № 2. C.154-156.
4. Конструирование программного обеспечения / Сост. А. А. Романов. Ульяновск: Изд-во УлГТУ, 2016. 126 с.
5. Ярцев A. Жизненный цикл разработки программ // Механика софтостроения. URL: https://www.arbinada.com/ru/ comment/reply/39 (дата обращения 07.05.19).
6. Надежность и эффективность в технике: Энциклопедический справочник. Т. 1: Методология. Организация. Терминология / под ред.д.т.н. А. И. Рембез. М.: Машиностроение, 1986. 224 с.
7. Автоматизированные системы управления технологическими процессами. Условия создания. Представление информации персоналу. Нормы и требования. Временные методические указания: Приложение 1 поряжению ПАО»РусГидро» от 19.01.2017 № 17р. 38 с.
8. Сызранцев Г. В. Управляемость системы связи // Известия Российской академии ракетных и артиллерийских наук. 2012. Вып. 2 (72). С. 81-86.
9. Zeldman J. Taking Your Talent to the Web: Making the Transition from Graphic Design to Web Design. Indianapolis: New Riders, 2001. 448 p.
10. Zadeh L. Fuzzy logic, neural networks, and soft computing // Communications of the ACM. 1994. Vol. 37. No. 3. Pp. 77-84.
11. Durugboa Ch., Tiwarib A., Alcock J. R. Modelling information flow for organisations: A review of approaches and future challenges // International Journal of Information Management. 2013. No. 33. Pp. 597-610.
12. Burdo G. B., Semenov N. A. Principles of creating hybrid integrated automated systems of technological process design and control // Software & Systems. 2018. Vol. 31. No. 1. Pp. 107-111.
13. Ganchenko V., DoudkinA., InyutinA., Marushko Y. Neural network software diagnosis system of telemetry data // Proc. of the 7th International Conference "Intelligent Data Acquisition and Advanced Computing Systems (IDAACS)" (Berlin, Germany, September 12-14, 2013). IEEE, 2013. Vol. 1. Pp. 376-380.
SELF-DIAGNOSTICS AS A BASIS FOR CONSTRUCTION OF NETWORK TECHNOLOGICAL MANAGEMENT SYSTEMS FOR SPECIAL PURPOSE COMMUNICATION SYSTEMS
ELENA V. VERESHCHAGINA, KEYWORDS: communication system (network); control channel;
St-Petersburg, Russia, vereshagev@mail.ru telemetry; network process control system; monitoring.
ALEKSANDR I. TOLSTIHIN,
St-Petersburg, Russia, tolstihin91@mail.ru
ALEKSANDR P. NEVEROV,
Moscow, Russia, apnewerov@mail.ru
ABSTRACT
The general principles of creating an efficiently functioning management system for complex organizational and technical systems, such as communication systems, are formulated. The options for building a network technological control system of communication equipment for special-purpose communication systems, in particular,
communication systems with data encryption in the process control channel, are considered. The description and requirements for the upper and lower levels of the software are given. The necessity of the "modular" principle of software construction is grounded. The relationships between software modules and the operation of software
X<N\ \\\\ Ч>Л\\ \\\\
НАУКОЕМКИЕ ТЕХНОЛОГИИ В КОСМИЧЕСКИХ ИССЛЕДОВАНИЯХ ЗЕМЛИ, Т
'АДИОТЕХНИКА И СВЯЗЬ
№ 4-2019
by control hierarchies in the event of a failure in the operation of individual software modules or in the event of emergency situations on a communication network and / or in a network process control channel are described. The rationale for the implementation of telemetry functions and monitoring the status of individual software modules and the entire network process control system is presented. The system of protection and security of the system of network technological control with encryption in the channel of technological control is grounded. It was proposed to have means of long-term fixation and recording of events in the equipment for their restoration and correct operation of the network process control system after the restoration of communication with the equipment. The methods of differentiation of user rights in the system of technological control of communication equipment are presented and described. The procedure for verification of equipment control is described.
REFERENCES
1. Ermishyan A. G. Teoreticheskie osnovy postroeniya sistem voennoj svyazi v ob'edineniyah i soedineniyah. Chast' 1. Metodologichesk-ie osnovy postroeniya organizacionno-tehnicheskih sistem voennoj svyazi [Theoretical Foundations of Building Military Communication Systems in Unions and Unions: A Textbook. Part 1. Methodological basis for the construction of organizational and technical systems of military communications]. St. Petersburg: Voennaya akademiya svyazi Publ., 2005. 740 p. (In Russian)
2. Volik B. G. (Ed.) Teoriya upravleniya: Terminologiya [Management Theory: Terminology]. Moscow: Nauka, 1988. 262 p. (In Russian)
3. Sonkin M. A., Yammpolsky V.Z. Obobshchennye svoystva spetsi-al'nykh sistem svyazi i monitoringa dlya trudnodostupnykh i podvizh-nykh ob"ektov [Generalized properties of special communication and monitoring systems for remote and mobile objects]. Bulletin of the Tomsk Polytechnic University. 2008. Vol. 312. No. 2. Pp. 154-156. (In Russian)
4. Romanov A. A. (Ed.). Konstruirovanie programmnogo obespech-eniya [Software engineering]. Ulyanovsk: Ulyanovsk State Technical University Publ., 2016. 126 p. (In Russian)
5. Yarcev A. Zhiznennyj cikl razrabotki program [Life cycle of development of programs]. Mehanika softostroeniya [Mechanics of a softostroyeniye]. URL: https://www.arbinada.com/ru/comment/re-ply/39 (date of access 07.05.19). (In Russian)
6. Rembez A. I . (Ed.). Nadezhnost' i 'effektivnost' v tehnike: 'Encik-lopedicheskij spravochnik. T.1: Metodologiya. Organizaciya. Terminologiya [Reliability and efficiency in technology. Vol. 1: Methodology. Organization. Terminology]. Moscow: Mashinostroenie, 1986. 224 p. (In Russian)
7. Avtomatizirovannye sistemy upravleniya tehnologicheskimi pro-cessami. Usloviya sozdaniya. Predstavlenie informacii personalu Normy i trebovaniya [Automated process control systems. Creation conditions. Submission of information to personnel. Norms and requirements]. Temporary methodical instructions: Order of PAO RusHydro of 19.01.2017 No. 17r. 38 p. (In Russian)
8. Syzrantsev G.V. Upravlyaemost' sistemy svyazi [Manageability of the communication system]. Izvestiya Rossijskoj akademii raketnyh i artillerijskih nauk [Bulletin of the Russian academy of rocket and artillery sciences]. 2012. No. 2 (72). Pp. 81-86. (In Russian)
9. Zeldman J. Taking Your Talent to the Web: Making the Transition from Graphic Design to Web Design. Indianapolis: New Riders, 2001. 448 p.
10. Zadeh L. Fuzzy logic, neural networks, and soft computing. Communications of the ACM. 1994. Vol. 37. No. 3. Pp. 77-84.
11. Durugboa Ch., Tiwarib A., Alcock J. R. Modelling information flow for organisations: A review of approaches and future challenges. International Journal of Information Management. 2013. No. 33. Pp. 597-610.
12. Burdo G. B., Semenov N. A. Principles of creating hybrid integrated automated systems of technological process design and control. Software & Systems. 2018. Vol. 31. No. 1. Pp. 107-111.
13. Ganchenko V., Doudkin A., Inyutin A., Marushko Y. Neural network software diagnosis system of telemetry data // Proc. of the 7th International Conference "Intelligent Data Acquisition and Advanced Computing Systems (IDAACS)" (Berlin, Germany, September 12-14, 2013). IEEE, 2013. Vol. 1. Pp. 376-380.
INFORMATION ABOUT AUTHORS:
Vereshchagina E. V., Engineer of the Open Joint-Stock Company "SUPERTEL", St. Petersburg;
Tolstihin A. I., Engineer of the Open Joint-Stock Company "SUPERTEL", St. Petersburg;
Neverov A. P., Deputy Head of Department of the Federal State Budgetary Institution MIR IT.
For citation: Vereshchagina E. V., Tolstihin A. I., Neverov A. P. Self-diagnostics as a basis for construction of network technological management systems for special purpose communication systems. H&ES Research. 2019. Vol. 11. No. 4. Pp. 22-28. doi: 10.24411/2409-5419-201810276 (In Russian)
