Пакет поддержки пользователей

Размещено на http://www.allbest.ru/

1. Пакет поддержки пользователей (ППП/USP)

1.1 Администратор обеспечения пользовательских процессов

Опыт разработки систем реального времени (СРВ) доказал необходимость декомпозиции ФПО на собственно приложения, определяемые спецификой (точнее специальностью) СРВ и интерфейса этих приложений с операционными системами реального времени. Этот подход весьма распространен при разработке сложных программных систем и получил название «промежуточный слой», Middle Ware и т.п. В данном случае все услуги, связанные с обслуживанием собственно приложений, и не несущие на себе специфики СРВ выделены в пакет, получивший название «Пакет поддержки пользователей» или «User Support Package»(USP). Этот пакет должен обеспечить решение следующих задач:

Начальная загрузка пользовательских приложений (Boot Strapping User Tasks).

Обеспечение штатной работы по сигналу «Тактовый импульс»(ТИ).

Связь вычислительных модулей ПД между собой с помощью PCIeXpress (PCIe) и PCIcompakt(PCIc).

Связь вычислительных модулей ПД между собой с помощью Fibber Channel (FC).

Связь Единой вычислительной система(ЕВС) с внешними абонентами(ИУС и др.) с помощью Fibber Channel (FC и FC-TV).

Связь ЕВС с внешними абонентами с помощью РКИО(ARINC 419).

Обеспечение высокой готовности (борьба с деградацией, диагностика отказов программного обеспечения и аппаратуры, горячее резервирование модулей ПД).

Межмодульная синхронизация часов в рамках отдельно взятой БЦВМ.

Синхронизация часов между БЦВМ входящих в состав ЕВС.

Синхронизация по сигналам службы единого времени (СЕВ) с внешними вычислительными средствами (ИУС и др.).

Поддержка стендовой работы программиста и оператора-испытателя(USER SHELL).

Регистрация событий в системе ( временных диаграмм и др).

Программные средства контроля работы программ.

Набор и обработка статистических данных работы программ.

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

Список задач в процессе разработки ФПО может изменяться, дополняться и уточняться.

Состав модулей и структурная схема ППП приведены на рис. 1.

Администратор начальной загрузки пользовательских приложений

«Администратор начальной загрузки пользовательских приложений» (Boot Strapping User Tasks Manager). В его задачу входит «раскрутка» системы с инициализацией всех необходимых данных для штатной потактовой работы, внутри и межмодульной синхронизации часов, а также при необходимости синхронизация по сигналам службы единого времени (СЕВ). После того как инициализация(«Начальный пуск») завершится, начинается штатная (потактовая) работа.

«Сетевой администратор»

Модуль с названием «Сетевой администратор» обеспечивает информационной коммуникацией с внешними абонентами для процессорного модуля весь пакет пользователя с помощью служб ОСРВ «БАГЕТ 3.0», в частности, с помощью ППМ. Все особенности организации PCIeXpress, PCIcompakt, Fibber Channel, РКИО, линий дискретных сигналов(ДС) и др. для пользователя являются «прозрачными».

С помощью «Администратора сети» можно запускать или останавливать процессы (в том числе различные администраторы) на любой машине в сети СОЛО.

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

- масштабировать приложения;

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

- переносить выполнение приложения с одного процессора многомодульной машины на соответствующий модуль ЭВМ «горячего резерва» и распределять все процессы между модулями ЭВМ в процессе разработки;

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

1.2 Обслуживание линий дискретных сигналов (ДС)

По линиям ДС приходят от ОСРВ сообщения о тактовых импульсах(ТИ) из синхронизатора(внешние часы) и сигналы единого времени от ИУС. По сигналам ТИ осуществляется согласование вычислительных процессов в ЕВС. По сигналам единого времени осуществляется синхронизация всех вычислительных средств КБО.

Информационные сети

Несколько сложнее обстоит дело с информационными сетями. Рассмотрим два процесса, которые должны взаимодействовать: клиентский процесс и серверный процесс (в данном случае процесс, реализующий работу администратора порта Y_dev). В случае одного узла, клиент просто вызывает функции ореn(), rеаd(), write() и т. д. Высокоуровневые вызовы, например, ореn() порождают ряд низкоуровневых вызовов ядра, управляющих обменом сообщениями. Однако для клиента все эти функции оказываются "под поверхностью" и ему нет необходимости заботиться о них -- он просто вызывает ореn(), например:

fd = ореn ( "/dev/Y_dev" ,O_RDWR. . . . ) ; /*0ткрыть устройство X_dev*/

Если имеем случай простой сети с двумя машинами( или модулями): на одной находится клиентский процесс, на другой -- серверный, то программный код, необходимый для реализации клиент-серверного взаимодействия, будет идентичен тому, который используется в случае с одним узлом, за важным исключением: путевое имя. Путевое имя будет содержать префикс, задающий узел, на котором расположена данная служба (/dev/Y_dev). Этот префикс преобразуется в дескриптор узла, предназначенный для последующего низкоуровневого вызова СоnnесtAttach() или ему подобный. Каждый узел в сети имеет свой дескриптор.

Разрешение имен и поиск

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

Пространство имен путей на удаленных узлах отображается с префиксом /net (каталог создаваемый администратором сети, по умолчанию).

Например, удаленный узел node1 будет отображаться следующим образом:

/net/node1/dev/socket

/net/node1/dev/ser1

/net/node1/home

/net/node1/bin

При работе с «Администратором сети» можно обращаться к файлам или администраторам на других удаленных узлах так же, как открывать каналы(файлы) локально на своем собственном узле. Это значит, что имеется доступ к файлам или администраторам на других узлах сети , как если бы они находились на локальном узле.

Рассмотрим функцию ореn(). Если нужно открыть (установить связь) устройство не на локальной машине, а на узле node1, необходимо просто указать следующий путь:

fd = ореn ( "/net/node1/dev/Y_dev" ,O_RDWR. . . . ) ; /*0ткрыть устройство Y-dev на узле node1*/

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

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

Если дескриптор узла fd	то сервер
0	локальный (т. е. "данный узел")
Ненулевой	Удаленный

Идентификатор соединения (Файловый дескриптор)

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

Именование сетевых ресурсов (Адресная книга)

При разрешении имен в сетевом пространстве путевых имен используются определенные термины.

Имя узла -- последовательность символов, которая идентифицирует узел. Следует отметить, что имя узла не может содержать косых черт или точек. В приведенном примере в качестве имени одного из узлов мы использовали lab2.

Домен узла -- последовательность символов, которая "прикрепляется" к имени узла. Имя узла и домен узла вместе должны образовывать последовательность, уникальную для каждого узла.

Полностью определенное имя узла -- последовательность символов, состоящая из имени узла и домена узла.

Сетевой каталог -- каталог в пространстве имен путей, организованном администратором сети. Каждый сетевой каталог связан со своим доменом узла.

Разрешение имен -- процесс, с помощью которого администратор сети преобразует символьные имена в список адресов назначения.

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

Качество обслуживания -- определение качества соединения между двумя узлами.

пользователь дискретный сеть соединение

1.3 Качество обслуживания и резервированные соединения

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

Политики качества обслуживания

Сетевого администратора должен поддерживать обмен по нескольким сетям(FC, PCIc и др). Для этого предусмотрены следующие политики качества обслуживания, которые определяют, каким образом сетевой администратор должен выбирать сетевой протокол для передачи:

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

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

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

По умолчанию

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

Eсли какой-то канал связи обрывается, «Администратор сети» должен обеспечить переключение передачи на другой доступный канал. После этого «Администратор сети» "знает", что данный канал не работает и поэтому не будет использовать его для передачи пользовательских данных.

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

Заданный приложением

При использовании этой политики задается предпочтительный канал связи. «Администратором сети» должен использовать только этот канал, при условии, что он остается работоспособным.

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

Как только предпочтительный канал связи восстанавливается, «Администратором сети» возвращается к этому каналу и снова использует только его, игнорируя все остальные до тех пор, пока предпочтительный канал не откажет опять.

Личный

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

Если этот канал связи откажет, «Администратором сети» НЕ будет использовать другие каналы(FG Video).

Задание политик качества обслуживания

Политика качества обслуживания задается как часть путевого имени. Например, для того чтобы открыть доступ к /net/lab0/FCTV - политикой «личный», следует использовать следующее имя пути:

/net/lab0~exclusive:FCTV

Параметр всегда начинается с символа тильды (~). Таким образом, в приведенном примере «Администратору сети» задают команду использовать исключительно интерфейс FCTV, даже в том случае, если он даст сбой.

1.4 Символьные ссылки (псевдонимы)

Для различных путевых имен в «Адресной книге» с заданными политиками можно назначать символьные ссылки(псевдонимы). Преимущество здесь состоит в том, что при написании приложений можно использовать абстрактные "имена служб" вместо точных имен узлов.

Администратор пользовательских приложений

В Модуль с названием «Администратор пользовательских приложений» входят следующие функциональные субмодули:

Субмодуль приема и обработка информации от сетевого администратора о режимах работы системы.

Субмодуль коммутации сообщений о ТИ, сообщений о режимах РЛ и информационных сообщениях.

Субмодуль активизации требуемого набора («расписания») пользовательских Partition (процессов) с передачей информации этим наборам о режиме работы системы.

Администратор службы единого времени

Модуль с названием «Администратор службы единого времени» обеспечивает согласование на программном уровне всех часов внутри ЕВС на всех микропроцессорных модулях и (при необходимости) осуществляет привязку внутренних для ЕВС часов к часам внешней для ЕВС системы ИУС. Координатная информация, которая отправляется в ИУС, должна иметь временную метку для идентификации информации из других источников. Метки точного времени необходимы также внутренним в ППП алгоритмам накопления/обработки статистических данных внутри пакета для мониторинга процесса функционирования ФПО и информирования «Администратора высокой готовности».

Синхронизация часов по сигналам единого времени или часам ИУС.

1. Синхронизация часов внутри «СОЛО»

Модуль «Администратор службы единого времени», работающий на каждом модуле, выдает всем соседним модулям по линии PCIе значение собственных локальных часов. В результате каждый модуль имеет идентичные четверки значений {ti}. В каждом i-м модуле «СОЛО» вычисляется tСОЛО = =max{ti} и затем ?ti =- ti (для модуля i такого, что =ti имеем ?ti=0; i=1,4).

2. Синхронизация часов 2-х «СОЛО»

Аналогично производится синхронизация часов между «СОЛО»: по линии FC один из модулей посылает своему дублеру значение своих внутренне синхронизированных часов j(j=1,2) и затем вычисляется tЕВС=maxj и затем ?j= tЕВС - j (для СОЛОj такого, что tЕВС= j имеем ?j=0, j=1,2).

Синхронизация часов внутри «СОЛО» и синхронизация часов 2-х «СОЛО» производится на этапе начального (“холодного”) пуска (старта). Если в процессе работы произошел “горячий” рестарт процесса, то свое время модуль восстанавливает по времени взятом из PCIе от соседних модулей или по линии FC от СОЛО-дублера.

Итак, синхронизированное время в каждом вычислительном модуле каждого СОЛО вычисляется.

3. Синхронизация с часами ИУС производится аналогично:

По пришествию дискретного сигнала запоминается время его прихода tо=tЕВС, затем после получения значения tиус по линии FC-МКИО вычисляется поправка ?tиус=tиус-tо и эта поправка затем рассылается по PCIе и FC от принимающего модуля всем остальным вычислительным модулям, т.е. на j-м СОЛО и в i-м модуле в итоге расчет меток времени производится по формуле:

tлок.в =tЕВС+?tиус =ij+?tj +?tиус=ti+?ti+?j+?tиус

Если сигнал времени tиус не приходит, то сохраняется предыдущее значение ?tиус, а если не было ни одного сеанса сверки часов , то ?tиус=0.

Если дискретный сигнал будет отсутствовать, а значения tиус будут приходить по линии FC-МКИО, то момент коррекции определяется сменой значения tиус.

4. Синхронизация внутри процессорного модуля (замер времени).

Замеры времени внутри одного процессорного модуля с помощью системного вызова(sys_call) значения времени предназначены для:

Привязки временной метки к информации, выдаваемой в ИУС.

Трассировки событий типа “переключение патиций и процессов” для нужд контроля прохождения ФПО(см. описание модуля «Администратор высокой готовности пользовательских процессов»). Регулярное прохождение контроля сопровождается выдачей в процессорный модуль-дублер сообщений типа “пульсация” и возможно другой информации. При аппаратном отказе процессорного модуля или при программном отказе ФПО в защищенном адресном пространстве (Partition) выдача сигналов исправности прекращается и по истечении, например, 2-х несостоявшихся по этой причине сеансов связи вычислительный модуль-дублер на резервном «СОЛО» переходит в основной режим переключая на себя все коммутаторы, а отказавший модуль получает сообщение о необходимости произвести горячий рестарт. После рестарта модуль с установленной работоспособностью становится дублером.

Администратор высокой готовности

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

Администраторы каждого вычислительного модуля связаны между собой посредством каналов FC, PCIe и PCIс. Следовательно, модуль «Администратор высокой готовности» может работать в качестве канала связи, по которому составные части системы могут получать и передавать информацию, это может быть сделано для временной синхронизации, при межпроцессорном взаимодействии. Также, связь обеспечивает взаимозаменяемость администраторов, при выходе из строя одного из процессоров. Во время работы один администратор находится в режиме «ведущего», другой - «ведомый», отслеживают его работоспособность по импульсам от него приходящим. В случае пропуска «сеанса связи» некоторое, заранее определённое число раз, принимается решение о неработоспособности администратора, а вместе с ним и модуля. После чего «ведомый» становится новым «ведущим». Затем новый «ведущий» посылает сигналы «горячего рестарта» вышедшему из строя модуля для восстановления и продолжения работы в режиме «ведомого» т.е. нового «дублёра».

1.5 Администратор мониторинга пользовательских процессов (User Partition)

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

Буфер модуля «Мониторинга пользовательских процессов» может иметь различную структуру, но главное то, что объём записываемых данных целиком зависит от выделенной под него памяти, и частоты делания среза о состоянии системы. В буфер записывается вся информация о событиях, её полнота зависит от требований, предъявляемых к системе. Очевидно, что минимально необходимые данные, это:

1. Событие: изменение состояния патиции (процесса) - активна, приостановилась, была перезапущена, блокирована по недоступному ресурсу(критическая секция) и т.д...

2. ID патиции породивших событие.

3. ID процесса породивших событие.

4. Время события.

Во время рабочего режима каждая сущность (патиция, процесс) должна сообщать своё состояние и изменение состояния администратору с некоторым временем дискретизации. А в режиме трассировки администратор должен сам порождать события с целью получения информации о состоянии системы.

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

Кроме того, данная информация может быть использована «Администратором пользовательских процессов» при планировании работы СРВ.

Администратор внешнего сервиса

Модуль с названием «Администратор внешнего сервиса»(пользовательский shell) предназначен для организации диалогового режима при работе с ФПО и связанной с ЕВС реальной аппаратурой при работе при автономной и комплексной отладке на АРМ-121 и стендах МО и ГК. На ПЛИ с использованием аппаратуры КРАСа данный интерфейс позволит производить документирование и анализ исключительных ситуаций в виде неисправностей и отказов, возникших при реальной работе. Этот администратор должен иметь высокую модифицируемость для увеличения своей функциональности. На него возлагаются следующие задачи:

контроль и отладка программных и аппаратных коммуникаций с помощью широковещательных или адресных ping/echo пакетов;

управление условиями генерации событий;

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

организацию останова ЕВС безусловно или исходя из какого-либо множества заданных фильтров;

возможность установки потактовой работы и возврата на автоматический режим;

хранение информация об отфильтрованных событиях во внутреннем циклическом буфере;

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

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

1.6 Администратор поддержки пользовательского процесса (User Partition)

Модули с названием «Администратор поддержки пользовательских процессов (User Partition)»являются контейнерным каркасом для прикладных пользовательских функций. Состав модулей и структурная схема отдельного такого модуля приведена на рис. 2.

Администратор начальной загрузки пользовательского процесса

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

Канальный администратор

Модуль с названием «Канальный администратор» производит обмен сообщениями между Администратором пользовательских процессов - сообщения о ТИ, Администратором службы единого времени - значение меток времени и Пользовательскими прикладными процессами - информация для взаимодействия. Кроме того, данный модуль отправляет диагностическую информацию в модуль «Администратор высокой готовности» для дальнейшей обработки.

Локальный диспетчер пользователя

Центральное место занимает модуль с точкой регистрации(подключения) «Локального диспетчера пользователя». В него входят следующие функциональные субмодули:

Субмодуль приема и обработка информации от канального администратора о режимах работы системы

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

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

Администратор высокой готовности пользовательских потоков.

Диагностикой состояния ППЗ занимается модуль «Администратор высокой готовности пользовательских потоков». На него также возложены обязанности мониторинга пользовательских потоков т.е. ведение трассировки наиболее важных параметров работы системы. Статистическая информация передается в модуль «Администратор внутреннего сервиса», а сбор и передача результатов трассировки и протоколирования событий, произошедших в прикладном процессе модулю «Администратор высокой готовности» уровня «Администратора обеспечения пользовательских процессов».

Администратор внутреннего сервиса

Модуль «Администратор внутреннего сервиса» занимается накоплением локальной статистической информации и передачей этой информации через модуль «Канальный администратор» модулю «Администратор внешнего сервиса» и далее во внешний мир для обработки оператором стенда (программистом-разработчиком или программистом-тестировщиком).

Отображение пакета поддержки пользователя на ресурсы ЕВС уточняется с разработчиками ОСРВ «БАГЕТ 3.0» в процессе реализации исходя из требований безопасности ОСРВ и производительности - снижения накладных расходов на переключение контекста.

Размещено на Allbest.ru