Стандарты и протоколы автоматизированного администрирования и мониторинга бортовой локальной вычислительной сети Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.075

СТАНДАРТЫ И ПРОТОКОЛЫ АВТОМАТИЗИРОВАННОГО АДМИНИСТРИРОВАНИЯ И МОНИТОРИНГА БОРТОВОЙ ЛОКАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ

© 2014 К.Н. Храменкова

Санкт-Петербургский государственный университет аэрокосмического

приборостроения

Поступила в редакцию 30.09.2014

В статье рассматривается стандарты и протоколы автоматизированного администрирования и мониторинга бортовой локальной вычислительной сети.

Ключевые слова: администрирование, мониторинг, стандарт, протокол, обзор

Создание и запуск спутника является дорогостоящим мероприятием и требует большой точности в работе и внимания к деталям. Бортовая сеть космического аппарата включает в себя систему навигации, ориентации и стабилизации, специальные целевые устройства, которые могут выполнять различную полезную нагрузку. От скорости, качества и корректности работы всей системы зависит успешность работы всего спутника в целом и выполнение его задач и функций (например, съемка Земли, навигация на Земле). Неизбежно встает вопрос о конфигурировании и администрировании бортовой сети. После подключения всех устройств (узлов) и маршрутизирующих коммутаторов распределенной системы, необходимо ее сконфигурировать. Другими словами, необходимо поддерживать обмен данными между различными служебными модулями, специальными устройствами и датчиками. В ряде стандартов (InfiniBand, AFDX, FibreChannel) предложены свои методы администрирования, мониторинга и реконфигурирования сети. Для стандарта Space-Wire так же предложены разные варианты алгоритма Plug-and-Play (NASA, SOIS, SPA, University Dundee). Данная статья посвящена обзору перечисленных стандартов.

Стандарт MIL-STD-1553. Это стандарт Министерства обороны США, представляет собой магистральный последовательный интерфейс с централизованным управлением, применяемый в системе электронных модулей. Типичная шина MIL-STD-1553B (рис. 1) может состоять из:

1. двух каналов (основного и резервного)

2. контроллера шины

Храменкова Ксения Николаевна, инженер. E-mail: ksenia. khramenkova@guap. ru

3. оконечных устройств

4. монитора канала

Основная шина

Рис. 1. Типичная шина MIL-STD-1553

Особенностью интерфейса является двойная избыточная шина передачи информации, полудуплексный протокол «команда-ответ» и до 31 оконечного устройства. Основная функция контроллера шины - предоставление контроля потока данных для всех передач по шине. Дополнительно для инициализации всех передач данных Контроллер шины должен передать, принять и согласовать передачу информации на шине данных. Вся информация передает в режиме вопрос/ответ - Контроллер шины отправляет команду Оконечным устройствам, которые отвечают. Контроллер шины, согласно MIL-STD-1553B, - «ключевая часть данных шинной системы» и «основа контроля передачи информации в шине должна располагаться на контроллере шины, который должен инициализировать все передачи». Шина может поддерживать несколько контроллеров шины, но только один может быть активен в один момент времени.

Обычный контроль потока данных Контроллером шины включает передачу команд к Удаленному терминалу в заранее определенные временные интервалы. Команды могут включать

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

Иными словами, контроллер:

• оперирует командами из списка в своей внутренней памяти

• командует оконечным устройствам послать или принять сообщения

• обслуживает запросы, получаемые от оконечных устройств

• фиксирует и восстанавливает ошибки

• поддерживает историю ошибок.

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

Монитор канала отличается от оконечного устройства тем, что не может передавать сообщения по шине. Его роль заключается в мониторинге и записи транзакций по шине, без вмешательства во взаимодействие контроллера и оконечных устройств. Эта запись может быть использована для последующего анализа [1]. Планируется восстановление стандарта Управления Настройкой в 2014-2015 гг. Предыдущий датируется 1992 г. и позже был закрыт (стандарт MIL-STD-973).

Протокол SpaceWire Plug-and-Play (ECSS ESA-ESTEC). SpaceWire стандарт - один из ECSS стандартов, направленных на применение в области управления, разработки и качества продуктов в космических проектах и приложениях. ECSS является совместным проектом Европейского космического агентства, национальных космических агентств и Европейских промышленных объединений. Он был создан с целью развития и поддержания открытых стандартов. Одной из основных целей стандарта является обеспечение совместимости с различными видами оборудования и многофункциональное использование конечных элементов и подсистем. Назначения этого стандарта:

- упростить проектирование бортовых высокопроизводительных систем обработки данных.

- сократить затраты на внедрение систем.

- повысить совместимость оборудования обработки данных и подсистем.

- поддержать многоразовое использование (reusing) вычислительного оборудования для решения различных задач.

SpaceWire специально разработан для применения в бортовых системах космических аппаратов [2]. Цель SpaceWire Plug-and-Play -предоставление возможностей для определения или идентификации известных и неизвестных устройств в сети SpaceWire с известной или неизвестной топологией. Протокол также предлагает функции для поддержки управления основными элементами сетей SpaceWire, таких как определение ошибок на линках и управление процессом присвоения адресов. Протокол использует постоянный и расширяемый механизм для демонстрации управляющих параметров SW протоколов и сервисов или приложений, использующих SpaceWire. SpaceWire Plug-and-Play протокол также может быть использован для определения и управления любым протоколом или сервисом, расположенным на сети SpaceWire.

SpaceWire Plug-and-Play протокол рассматривает SpaceWire сеть с точки зрения связанных SpaceWire протоколов. К пользователям Space-Wire протоколов ссылаются как к приложениям. С точки зрения Plug-and-Play протокола, эти приложения являются конечными источниками и назначениями SpaceWire пакетов. Для того, чтобы рассылать сообщения по сети SpaceWire, каждое приложение использует набор протоколов передачи, где самый нижний уровень будет SpaceWire. Эти протоколы формируют уровни стека передачи информации.

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

Рис. 2. Стеки протоколов и приложений в устройствах

fПриложе 1

vEy

Протокол 4

Протокол 3

Протокол 1

Роутер

SpaceWire

Узел

Приложе Приложе Приложе Приложе

Протокол 4

Протокол 3

Протокол 1 Протокол 2

SpaceWire

SpaceWire Plug-and-Play протокол допускает простую уровневую архитектуру (2 уровня): сервис сетевого управления и протокол передачи данных. Сервис сетевого управления на контролирующем устройстве отвечает за сетевое изучение, идентификацию устройства и действия по настройке, используя протокол передачи данных. Периферийное устройство позволяет выполнять настройку через настраиваемые параметры, доступ к которым осуществляется через протокол передачи данных. сервис сетевого управления на контролирующем устройстве не обращается напрямую к SpaceWire протоколу передачи данных. Доступ к протоколу абстрактен благодаря использованию драйвера устройства. Это позволяет сервису сетевого управления управлять устройствами, которые не поддерживают стандартный SpaceWire протокол передачи данных или стандарт периферийного устройства сервиса сетевого управления [3].

Space Onboard Interface Services (SOIS). Международный Консультативный Комитет по Космическим Системам Передачи Данных (Consultative Committee for Space Data Systems, CCSDS) обладает большим успехом в стандартизации интерфейсов между космическим кораблем и наземной системой и расширяет свой успех на области такие, как интерфейсы стыковки к орбите. Основная цель в снижении стоимости и уменьшении риска для агентств и индивидуальных миссий. Это проявляется в:

• повторном использовании инфраструктуры миссии;

• разделение ресурсов между миссиями и агентствами;

• повторное использование аппаратного и программного обеспечения;

• сохранение базы знаний агентств;

• повторное использование стандартного электронного земного оборудования поддержки;

• расширенная проверка операций и полнота стандартов.

SOIS создан CCSDS и представляет собой стандартизированные сервисы для применения во всех типах миссий, включая научные и коммерческие, пилотируемые и непилотируемые. Сервисы SOIS предоставляют следующее:

- в связи с определениями протоколов, позволяют мобильность оборудования по всему КА (должны использоваться одни и те же каналы данных);

- в связи с стандартом API, позволяет мобильность исходного кода программного обеспечения по всему КА (могут быть использованы разные каналы данных);

- в связи с подсетевыми протоколами перехода, реализация Транспортного Уровня позволяет мобильность оборудования по всему КА (разные каналы связи);

• в связи со стандартизацией Сетевого и Транспортного Уровня, поддержка возможности взаимодействия между бортовым оборудованием КА через набор каналов данных.

SOIS дает ограниченное определение Plug-and-Play устройств, включающую активность в период проектирования, так же как и активности во «время исполнения» или «время работы», но исключающую динамическое исследование возможностей устройств во время исполнения.

Преимущества Plug-and-Play:

• возможность взаимодействия сетей. Позволяет приложению быть мобильным, аппаратное обеспечение может взаимодействовать, продвигает повторное использование и уменьшает стоимость разработки и функционирования. Plug-and-Play должен изолировать ПО и аппаратное обеспечение устройства, разрешать гибкость и развитие;

• приспосабливаемость. Plug-and-Play должен вводить возможность системы адаптироваться к изменениям, таким как изменения в устройствах или ПО. Такая приспособляемость не необходимый атрибут при реализации космической системы, но может взамен быть связана с

процессом разработки. Приспосабливаемость продвигает повторное использование и позволяет производить поздние изменения в процессе разработки системы или во время функционирования;

• скорость. Характеристики Plug-and-Play должны продвигать сокращенное время разработки, соучастие проектированию, реализации, интеграции и тестированию.

Далее описаны 4 сценария, иллюстрирующих использование Plug-and-Play:

1. Быстрая разработка КА. Техники Plug-and-Play используются для помощи при разработке КА. Получившаяся космическая система ожидается статичной все время работы, без требований к динамическому определению устройств или конфигурированию устройств. В этом случае приспосабливаемость Plug-and-Play в череде настроек разработки.

2. Автоматизированная интеграция и тестирование, сделанная например, с помощью Оборудования Земной Поддержки (GSE), инструменты тестирования и моделирования устройств, техники обнаружения устройства используются для поддержки интеграции, проверки интеграционных проблем и содействия автоматическому тестированию. В этом случае динамические аспекты Plug-and-Play использованы, но приспосабливаемость скорее применима на GSE, а не на КА.

3. Динамическое восстановление после ошибок. Способности определения устройства Plug-and-Play могут быть использованы для содействия FDIR (определение ошибки, изолирование и восстановление), верификации присутствующих устройств стандартным методом. Как только ошибка произойдет, восстановление может также использовать техники PnP, определение работающего дублирующего устройства и автоматическая реконфигурация подсети в ответ. Это обеспечивает ограниченную форму приспособляемости на бортовом ПО.

4. Динамическое перемещение устройства. Некоторые системы могут изменяться в ходе работы, такие как те, которые используют беспроводные каналы данных и могут появляться, пропадать или передвигаться; или те, которые физически изменяются благодаря человеческому или машинному вмешательству, опять же из-за изменений топологии подсети. В этих случаях, Plug-and-Play обнаружение устройств и конфигурирование сети используются для предоставления уровня бортовой приспосабливаемости, который может адаптироваться к вероятным изменением в подсети [4].

Space Plug-and-Play Avionics (SPA). Научно-исследовательская лаборатория

Воздушных сил разрабатывает систему на основе адаптации Plug-and-Play подходов для использования в космосе. Система Plug-and-Play (Space Plug-and-Play Avionics - SPA) основывается на управляемом интерфейсом наборе стандартов, способствуя быстрой разработке шин (платформ) и полезных нагрузок. Также SPA -платформа открытых систем, комбинирующая коммерческие стандарты с тщательно выбранными аппаратными и программными расширениями, необходимыми для современных встроенных систем реального времени (например, отказоустойчивость, более высокое питание, самоописание).

SPA без стандартов может быть реалии-зована в любой небольшой организации или небольшом наборе организаций. Базовая концепция этой Plug-and-Play технологии наземной компьютерной индустрии, которая может быть адаптирована для космоса, не является большой технической проблемой. Реализация SPA через широкую основу требует стандартов для определенных вещей: широкая функциональная совместимость с разнообразными производителями составляющих, экономически-эффективный интерфейс для производителей составляющих для построения, и быстрая конфигурация/реконфигурация так как космический аппарат составлен из многих компонентов (составляющих). Стандарты SPA обеспечивают объединенную методологи. Plug-and-Play, чтобы упростить быстрое развертывание космических систем, используя модульные компоненты. Космическая система обычно включает набор независимых разработчиков компонентов. SPA стандарты способствуют пониманию между производителями компонентов, так что, если их компонент совместим с SPA, то они могут ожидать полную функциональную совместимость с системе SPA. Plug-and-Play также разрешает приложение проектирования спутника drag-and-drop и другие схемы автоматизации концепций, которые позволяют проектировщику спутника быстро создавать требования к миссии, моделировать операции на орбите, корректировать проект по мере необходимости, и проверять проект перед сборкой спутника. Вместе с приложением технологии Plug-and-Play, инструментарии, которые поддерживают быстрое проектирование и тестирование SPA спутников являются критическими компонентами при достижении целей быстрого проектирования спутника, изготовления, интеграции и тестирования.

В SPA менеджер подсети - конструкция, которая образует присоединение к протоколу кроме того, что исходно поддерживается при

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

Фундаментальные роли менеджера по подсети (SMS) SPA SpaceWire описаны кратко в следующих пунктах:

- исследование всех узлов в сети и их связующих компонентов SPA

- выполнение любой работы, требуемой для конфигурации сетевой инфраструктуры для поддержки адресации

- запрашивание регистрации компонент подсети со Службой Поиска SPA в Сети SPA

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

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

-направление сообщения SPA полученное менеджером подсети (SMS) SPA SpaceWire от стороны SPA-L до конечной точки на подсети

- выпуск сообщений, прибывающих от подсети на SPA-L в надлежащей форме для локальной маршрутизации

- обеспечение возможности присоединения, когда два или более адаптера установлены на узле. Возможность передать сообщения от одной подсети другой, независимо от типа линии данных (среды передачи). [5]

Исследование топологии - процесс, которым SMS идентифицирует позиции маршрутизаторов и конечных точек в подсети SW. SPUTNIX создал собственный набор спецификаций, основанный на SPA - Sputnix Plug-and-Play Architecture specifications (SxPA). Это Plug-and-Play архитектура, которая имеет ключевую особенность в том, что быстро соединяет и конфигурирует микроспутниковые подсистемы с использованием Plug-and-Play принципа. Этот принцип позволяет подключать устройство в систему без его предварительной подготовки и

без подготовки контролирующей системы, т.е. автоматический процесс распознавания устройства и обмен данными между устройствами [6].

Avionics Full Duplex Switched Ethernet (AFDX). Основной целью стандарта ARINC 664 является создание детерминистской сети передачи данных, которая может быть использована для использования необходимыми для управления полётом системами. Эта цель достигается при помощи предоставления выделенных полос пропускания трафика для каждого маршрута информации в сети и обеспечения доступности спецификации качества обслуживания (QoS) на каждом узле системы. Каждая конечная система Avionics Full Duplex Switched Ethernet (AFDX) -часть большой масштабируемой сети данных самолета, которая имеет ряд функциональных требований, требований, связанных с безопасностью, и требований по работоспособности для исполнения. Такая сеть должна быть управляемой для определения и быстрого изолирования отказавших компонентов. Простой Сетевой Протокол Управления (Simple Network Management Protocol, SNMP) был разработан как общий стандарт для управления большими сетями и их компонентами.

SNMP основывается на модели менеджер/агент, состоящую из менеджера, агента, базы данных управляющей информации, управляемых объектов и сетевого протокола. Менеджер предоставляет интерфейс между человеком-менеджером сети и системой управления. Агент предоставляет интерфейс между менеджером и физическим управляемым устройством.

Рис. 3. Система AFDX

Менеджер и агент используют Информационную Базу Управления (Management Information Base, MIB) и относительно маленький набор команд для обмена информацией. MIB организован как древовидная структура с индивидуальными переменными, такими, как состояние

точки или описание, представленными как листья на ветках. Используется длинный числовой тэг или идентификатор объекта (OID) для различения каждой отдельной переменной в MIB и в SNMP сообщениях.

SNMP использует пять основных сообщений (Получить- GET, Получить Следующий — GET-NEXT, Получить ответ — Get-RESPONSE, Установить — SET, Прерывание — TRAP) для общения/связи между менеджером и агентом. Сообщения GET и GET-NEXT позволяют менеджеру запрашивать информацию об определенной переменной. Агент, после получения сообщения GET или GET-NEXT, выпустит сообщение GET-RESPONSE менеджеру либо с требуемой информацией, либо с сообщением об ошибке, по которой запрос не может быть обработан. Сообщение SET позволяет менеджеру запрашивать изменение специальной переменной, в случае удаленного сигнала, который будет управлять передатчик/реле. Агент ответит сообщением GET-RESPONSE, означающим, что изменения сделаны или показывать ошибку из-за которой изменения не могут быть сделаны. Сообщение TRAP позволяет агенту спонтанно сообщить менеджеру о важном событии. Небольшое количество используемых команд объясняется одной причиной - SNMP простой. Другой упрощающий фактор - это его надежность в неконтролируемом или канале данных без установления соединения. Это упрощение приводит прямо к его широкому использованию, в частности в Internet Network Management Framework. В рамках этой платформы рассматривают устойчивость из-за независимости менеджеров от агентов, например, если агент выйдет из строя, менеджер продолжит функционировать, верно и обратное [7, 8].

Modular Space Vehicle Bus. Modular Space Vehicle (MSV) реализует Открытый Модульный Системный Подход и SPA. Modular Open System Approach (MOSA) теперь называется Архитектурой Открытых Систем (Open Systems Architecture, OSA). OSA - деловая и техническая стратегия разработки новой системы или модернизации существующей. OSA позволяет техническим сообществам собирать и разрабатывать доступные изменения, использовать эволюционный сбор и спиральную разработку и разрабатывать интегрируемую карту для проектирования системы и разработки. Базирование стратегий проектирования на широко поддерживаемых открытых стандартах увеличивает шанс, что будущие изменения системы будут введены экономически-эффективным способом. Шина космического аппарата может быть собрана и интегрирована в полезную нагрузку в несколько

дней. Снабженный модельной радиочастотой (RF - radio frequency) и электро-оптической полезной нагрузкой, MSV шина обладает возможностями многоразового использования для передачи данных, тактически устойчивой логикой, контролем и исследованием, тактической электронной поддержкой и ситуативную осведомленность.

MSV способна к работе в низкой земле, средней и геосинхронных орбитах, размещает полезные нагрузки для обширного диапазон миссий, включая радарную обработку изображений, ракетное предупреждение, военную связь и погоду, и имеет продолжительность жизни/использования на орбите от 1 года до более 7 лет. Стандартные Plug-and-Play интерфейсы включают проверку полезных нагрузок до интеграции, и космический корабль может использовать общий тест оборудования для всех миссий, гибкая подсистема питания может быть сконфигурирована для многократных миссий, путем добавления или удаления батарей и солнечных батарей, и MSV система может разместить полезную нагрузку на последней минуте и составляющие шины изменятся с минимальным влиянием на стоимость и график/план. Оборудование MSV собрано на одной платформе с полезной нагрузкой, и все компоненты - объекты Plug-and-Play, которые могут быть свободно соединены между собой. Функции MSV команда и обработка данных (C&DH) подсистемы, которые состоят из девяти полетных Applique Sensor Interface Modules (ASIM) и одного роутера SPA SW с программным полетным обеспечением, включающим BroadReach процессор.

Центральный роутер SPA-S и устройство распределения питания предоставляют центральную сеть всех устройств, и SPA компоненты соединены с C&DH подсистемой через стандартный SPA соединитель/переходник или кабель. Другие компоненты не-SPA включая аст-роориентатор, датчики солнца и прочее — оснащены ASIM для электрического соединения их с SPA-S и SPA компонентами. Платформа полезной нагрузки оснащена батареями для хранения питания на несколько миссий и питание генерируется от солнечных панелей, смонтированных на крыльях. Подсистема связи включает и систему связи с землей для команд и контроля (SGLS) и общую линию связи радио данных, которая выполняет воспроизведение данных миссии прямо в развернутые полевые терминалы. Обмен SPA сообщениями между аппаратными и программными компонентами возможен через Менеджер Сервисов Спутника (SSM).[9]

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

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

1. использование общего теста оборудования для проверки полезной нагрузки до интеграции;

2. Гибкая система питания, которая может быть настроена, чтобы иметь больше или меньше батарей и солнечных батарей;

3. Возможность разместить полезную нагрузку на последней минуте и изменения компонентов шины не повлияют на стоимость и вре-мя.[10]

Выводы: рассмотрены концепции развития алгоритма Plug-and-Play в разных бортовых стандартах, приведен их краткий обзор. Сделан вывод о том, что технология SpaceWire является самой перспективной, на ней базируется часть алгоритмов Plug-and-Play и некоторые позволяют свободно ее использовать, либо создают дополнения. Рассмотренные алгоритмы применимы в основном для зарубежной техники и приборов, таким образом, встает задача создания алгоритма Plug-and-Play для отечественной аппаратуры.

СПИСОК ЛИТЕРАТУРЫ:

1. MIL-STD-1553 Tutorial, AIM GMBh, November 2010

2. ECSS-E-50-12C. SpaceWire - Links, nodes, routers and networks. - European Cooperation for Space Standardization (ECSS), 31 July 2008

4. Space engineering SpaceWire - Plug-and-play protocol, ECSS, 2013

5. Spacecraft Onboard Interface Services Information Report, CCSDS 850.0-G-2 Green Book 2013

6. Space Plug-and-Play Architecture Standards Development Guidebook, Guide, 2011

7. Plug-and-Play technology for microsatellites has been experimentally confirmedxam; URL:http://www. sputnix.ru/en/mediainfo/item/309-plug-and-play-tech nology-for-microsatellites-has-been-experimentally-confirmed, 2013

8. Architecting ARINC 664, Part 7 (AFDX) Solutions, 2009

9. Simple Network Management Protocol (SNMP), XILINX, 2013

10. Modular Space Vehicle (MSV) Bus, United States of America:cam; URL:http://www.airforce-technology.com/projects/modular-space-vehicle-msv-bus, 2014

11. Joey Cheng, Northrop's Modular Space Vehicle gives Air Force fast satellite capabilityxam; URL: http://defensesystems.com/Articles/2014/03/03/MSV-plug-and-play-satellite-

Northrop.aspx?admgarea=TC_DefenseIT&Page=1

STANDARDS AND PROTOCOLS OF THE AUTOMATED ADMINISTRATION AND MONITORING OF THE ONBOARD LOCAL COMPUTER NETWORK

© 2014 K.N. Khramenkova St. Petersburg State University of Aerospace Instrumentation

In article is considered standards and protocols of the automated administration and monitoring of the onboard local computer network.

Key words: administration, monitoring, standard, protocol, review

Kseniya Khramenkova, Engineer. E-mail: ksenia. khramenkova@guap. ru