Разработка программы поддержки пользователя СОЛО-35. 02

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

Целью данной курсовой является разработка программы поддержки пользователя СОЛО-35.02. В нее входит также программа «Диспетчер». Программа «Диспетчер» устанавливается на все МПД и является системной с точки зрения остальных функций ФПО. Диспетчер имеет наивысший приоритет в системе для сохранения работоспособности СЦВМ даже при «зависании» функций режимов. Диспетчер в первую очередь необходим для выполнения начального пуска, организации единого информационного пространства между МПД (организация и обеспечение межмодульного обмена), выполнения и контроля внешнего обмена по всем магистралям и линиям связи, обеспечения выполнения наиболее критичных ко времени выполнения задач управления системой, выполнения задач текущего контроля над системой, обеспечение работы СОК, контроль за версиями СПО запуском функций режимов. Примененный принцип централизации управления позволяет минимизировать логику работы системы в целом, облегчает построение «удаленного» управления РЛС (управление с процессоров на которых нет мезонина МПИ и других), в значительной мере облегчает обмен с внешними системами самолета, т.к. не приходится учитывать особенности каждого конкретного режима. Централизованное построение межмодульного обмена исключает возможные коллизии с «наложением» данных при обработке входных и выходных массивов, сбои в диаграмме межмодульного обмена, и гарантирует проведение обмена даже при сбоях и возникновении исключительных ситуациях в функциях режимов. Диспетчер гарантирует синхронный запуск функций режима с частотой тактового импульса или другого события для синхронной работы РЛС и функций режима. Многорежимность каждого диспетчера позволяет иметь на каждом МПД один или несколько функционально независимых режимов по аналогии с БЦВМ-900 или СОЛО-54.

Краткое описание архитектуры СОЛО-35.02

Специализированная цифровая вычислительная машина СОЛО-35.02 представляет собой 4-х процессорную вычислительную машину и базируется на архитектуре единой коммутируемой вычислительной среды (ЕКВС).

В качестве несущего конструктива использует корпус? ATR Short рисунок 1 (крейт).

Рисунок. 1

Основные технические характеристики и состав модуля процессора данных (МПД):

центральный RISC-процессор с частотой 800 МГц. Частота шины процессора — 64МГц;

внешняя шина Compact PCI модуля — 32(64) разряда с тактовой частотой 33 (66)МГц;

внутренняя шина PCI — 32 разряда с тактовой частотой 33МГц;

— емкость памяти SDRAM — 512 Мбайт с возможностью ее расширения до 1 Гбайт;

— емкость FLASH памяти — 2 Гбайт;

— емкость памяти Serial Boot Prom — 4 Мбайт;

— контроллер Ethernet 10/100Мбит/c ТР — 1 шт.;

— интерфейс дискретных сигналов: 4 входных и 4 выходных линии;

— порт RS-232С — 2 шт.;

— порт скоростного ввода/вывода данных, содержащий два полнодуплексных подканала (lane) с интерфейсом PCI Express;

— порт помехозащищенной промышленной сети CAN — 1 шт.;

— два слота М1 и М2, расположенные на локальной шине PCI и предназначенные для установки РМС — мезонинных модулей, соответствующих стандарту IEEE 1386.1.

Системный контроллер модуля, кроме контроллеров шин и интерфейсов, по которым осуществляется взаимодействие процессора МПД как с внутренними устройствами модуля, так и внешними, по отношению к МПД, устройствами, содержит таймеры, контроллер прерываний и контроллер прямого доступа (DMA), обеспечивающий любые возможные направления передачи SDRAM, шин Compact PCI и PCI.

В состав системного контроллера модуля входят два R-Таймера и 16 U-Таймеров. Все таймеры 32-х разрядные. R-Таймеры работают на частоте системной шины — 66.666 666 МГц, U-Таймеры работают на частоте системной шины деленной на 16. На каждом такте внутренний счетчик таймера уменьшается на 1 и при переходе через 0 может вызвать прерывание (в зависимости от настройки). Прерывания от каждого R-Таймера имеют отдельную линию в контроллере прерываний. Прерывания от всех U-Таймеров идут по одной линии в контроллер прерываний. Также имеется 32-х разрядный Watchdog-Таймер, который работает на частоте системной шины — 66.666 666 МГц. На каждом такте внутренний счетчик таймера уменьшается на 1 и при переходе через 0 происходит сброс процессора или модуля заданного типа. Кроме того имеется таймер в центральном процессоре, который работает на частоте равной половине частоты процессора. Его счетчик постоянно инкрементируется и при достижении заданного значения может вызвать прерывание. В терминологии ОС РВ аппаратные таймеры это часы. Часы центрального процессора используются операционной системой реального времени.

Связь между модулями осуществляется по двум каналам (lane) высокоскоростной последовательной шины PCI-Express, обеспечивающей пропускную способность до 2.5Гбит/c. Для передачи данных и коммутации применяется пакетный принцип, используются методы маршрутизации и управления потоками с поддержкой параллельного (группового) распределения данных, с контролем, обнаружением и парированием ошибок в каждом канале связи. Применение коммутируемых структур шины PCI-Express обеспечивает возможность одновременного функционирования множества соединений между любыми парами модулей, выбираемыми программно, осуществление полнодуплексного обмена по принципу «точка-точка» между модулями.

Коммутаторы (SWITCH) шины PCI-Express установлены на кросс-плате которая установлена в крейте СЦВМ СОЛО-35.02. Для обеспечения высокоскоростного обмена внутри каждого модуля ПД применяется параллельная шина PCI, к которой подключен контроллер Ethernet и могут подключаться два мезонина. Сигналы с мезонинов проходят через модуль МПД напрямую и с него выходят на кросс-плату, с которой выходят на разъемы крейта через гибкий шлейф;

Мезонинные модули, устанавливаемые на МПД в универсальной подсистеме СЦВМ, являются РМС-мезонинами (PCI Mezzanine Card), и по своей конструкции и габаритам удовлетворяют стандарту Р1386.1. Каждый мезонинный модуль содержит контроллер соответствующего интерфейса, доступный процессору МПД по PCI-шине, и аппаратные средства для реализации необходимых электрических характеристик интерфейса:

Мезонин 2Т201 представляет собой 2-х канальный контроллер мультиплексного канала информационного обмена (МКИО ГОСТ Р 52 070;2003) с резервированием. Каждый канал может работать в одном из режимов: «Контроллер шины», «Оконечное устройство» и «Монитор»;

Мезонин 2T101 представляет собой контроллер магистрали МПИ (ГОСТ 26 765.51−86). Работа возможна в режиме «Задатчик» и «Абонент». Мезонин формирует 8 независимых разовых команд, требующих внешней запитки +27В;

Мезонин 2Т001 представляет собой контроллер радиального канала информационного обмена (РКИО ГОСТ 18 977–79) и обеспечивает прием по 16 независимым каналам и передачу по 8 независимым каналам. Первые 4 приемных канала и 4 передающих канала могут работать с сигналом «готовность».

Таблица 1

Модуль процессора данных поступает к потребителю с записанным в ПЗУ Технологическим Монитором (ТМ) RedBoot. Одна из основных функций ТМ — запись в ПЗУ и файловую систему YAFFS2 на NAND флэше. Технологический монитор может записать образ операционной системы реального времени или сетевого загрузчика через порт RS232−2 на скоростях до 115 200 бод или через Ethernet. ТМ всегда получает управление при включении питания и перезапуске модуля по сигналу RESET. ТМ работает в двух режимах технологическом и боевом. В технологическом режиме ТМ позволяет через консоль RS232 или Ethernet выполнять настройки параметров загрузчика. После запуска загрузчика на консоль выдаются сообщения об инициализации и результатах самотестирования, и приглашение «Press „p“ to stop autoboot…», после чего выдерживается пауза 3 секунды в течении которых пользователь может нажать клавишу «p» на клавиатуре для остановки процесса загрузки:

Set CPU multiplier to 12

Resetting CPU for cache clear …

Hello from SOLO

Console at NS16550 UART’s A & B, mode: 115 200 8N1

This is UART B

TLB initialization … DONE

SDRAM Controller initialization … DONE

Testing SDRAM … OK

Copy image to RAM … DONE

Verify image CRC … OK

Jumping to RAM … DONE

Initialize PCI … DONE

Initialize onboard ethernet … DONE

Initialize NAND 512MB … DONE

Mount YAFFS 16MB boot partition … DONE

Starting POST — Press^C for abort! POST: SDRAM=OK NAND=OK PCI=OK PCIE=OK ETH=OK

Processor number on backplane 0

Waiting for module registration … backplane module mask=01b PD=01b

eth0: mac=00:00:00:06:00:16 ip=10.7.10.2 mask=255.0.0.0

eth1: mac=00:00:62:70:00:00 ip=7.0.0.1 mask=255.0.0.0

eth1: mac=00:00:62:70:00:00 ip=8.0.0.1 mask=255.0.0.0

Default server: 10.7.1.70

Press «p» to stop autoboot…

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

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

Модуль ПД установленный в первую позицию крейта является ведущим и обеспечивает задачи связи по Ethernet и эмуляцию Ethernet через PCI-Express и его маршрутизацию для остальных МПД, управление синхронной загрузкой и запуском остальных МПД. При помощи загрузчика есть возможность подключатся через локальный «telnet» к модулям МПД-1, МПД-3 и МПД-4 для настройки параметров начального пуска и встроенного тестирования.

Результаты тестирования и конфигурации Технологического Монитора (ТМ) сохраняются в структуре типа REDBOOT_RESULT по адресу 0xa0000a00. При старте образа ОС эта структура копируется в структуру с именем boardRedBootResult. Тип REDBOOT_RESULT определен в файле board.h. Для просмотра полей структуры есть функция из состава пакета поддержки модуля redbootShow ().

При помощи шины PCI-Express реализован механизм быстрой доставки так называемых «событий», которые представляют собой короткий пакет с информацией о версии и номере события и служат для межмодульной синхронизации и управляются программно. Для управления отправкой и приемом событий пользователю предоставляется библиотека EVT предназначенная для использования в однопотоковых приложениях или в приложениях без использования многопотоковых операционных систем, а также EVTMT (MultiThread) предназначенная для многопотоковых приложений в операционных системах удовлетворяющих стандарту POSIX. Существует два типа событий адресные, предназначенные для конкретного получателя в системе и широковещательные, предназначенные для всех известных получателей.

Для организации внутримашинной сети используется библиотека «Гермес» из состава пакета поддержки пользователя. Библиотека по сути реализует архитектуру «VIA» (Virtual Interface Architecture), разработанную компаниями Microsoft, Intel, Compaq. Архитектура «VI» предназначена для построения высокопроизводительных локальных сетей с минимальной прогнозируемой задержкой на доставку сообщений, что достигается за счет сокращения времени обработки в системном программном обеспечении на передачу сообщения по сравнению с традиционными сетевыми интерфейсами. За счет минимальных накладных расходов «VI» пригоден для применения в системах реального времени. К недостаткам «VI» можно отнести отсутствие широковещательной рассылки сообщений, обязательного наличия заданий на прием в приемной очереди и, как следствие, «разрыв» виртуального соединения в случае прихода сообщения в пустую принимающую очередь.

Концепция и принципы организации многопроцессорной вычислительной системы Для многопроцессорной системы предлагается разделить задачи на две категории:

локальные, выполняемые в каждом процессоре или МПД (модуле процессора данных);

глобальные, выполняемые в «ведущем» МПД, выполняющем задачи управления вычислительной системой в целом;

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

При разработке идеологии программы «Диспетчер» (далее диспетчер) и ФПО для СОЛО35.02 были выработаны следующие принципы исходя из особенностей многопроцессорной архитектуры единой коммутируемой вычислительной среды:

«Нить» диспетчера в каждом МПД имеет наивысший приоритет среди «нитей» ФПО;

Все функции логики управления и переключения режимов выполняются в контексте диспетчера (централизация управления);

Диспетчеры в каждом МПД должны поддерживать «многорежимность» по аналогии с СОЛО-54;

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

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

Межмодульное переключение режимов должно сводится к коммутации информационных потоков от МПД и выполняться диспетчером;

Диспетчеры в каждом МПД должны иметь «EMBCTRL» режим необходимый для выполнения задач начального пуска и встроенного контроля вычислительной системы (не боевых режимов!!!);

Все диспетчеры должны управлять процессом начального пуска каждый в своем МПД и обеспечивать выработку признака интегральной исправности МПД;

Диспетчеры должны контролировать все информационные потоки, приходящие на мезонины, установленные на МПД и проверять их соответствие заданным в протоколах обмена параметрам (темп поступления, количество слов и т. д.);

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

Диспетчер должен управлять обработчиком прерывания от внешнего тактового импульса или обработчиком иного события;

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

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

Диспетчер должен запускать только «нить-100Гц» при разрешении работы режимов с частотой тактового импульса или иного события;

Диспетчер должен контролировать завершение выполнения задач в «нити-100Гц» перед её повторным запуском в целях исключения «накопления» в её семафоре;

Все остальные «нити» режима запускаются из «нити-100Гц» т.к. они полностью принадлежат режиму и не требуются для работы диспетчера;

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

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

Все функции межмодульного обмена выполняются и контролируются в контексте диспетчера и (или) подчиненных только ему вспомогательных «нитях» если таковые требуются;

Все функции обмена с блоками контейнера и внешним БРЭО выполняются и контролируются диспетчером и (или) подчиненных только ему вспомогательных «нитях» если таковые требуются;

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

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

Любой режим обязан немедленно реагировать на изменение управления от диспетчера;

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

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

Диспетчер имеет право «перекоммутировать» информационные потоки с режима на себя в целях сообщения во внешние системы о возникновении исключительной ситуации (запись в СОК);

Каждый диспетчер должен иметь ряд «подсистем» необходимых для облегчения разработки программ режима и контроля его работы: «удаленная запись по шине МПИ», «СОК», «ПК100», «ПК-СОЛО» (разработка НИО-7), «FREC"(на стадии разработки НИО-7);

Описание программы «Диспетчер» для МПД СОЛО35.02

Программа «Диспетчер» устанавливается на все МПД и является системной с точки зрения остальных функций ФПО. Диспетчер имеет наивысший приоритет в системе для сохранения работоспособности СЦВМ даже при «зависании» функций режимов. Диспетчер в первую очередь необходим для выполнения начального пуска, организации единого информационного пространства между МПД (организация и обеспечение межмодульного обмена), выполнения и контроля внешнего обмена по всем магистралям и линиям связи, обеспечения выполнения наиболее критичных ко времени выполнения задач управления системой, выполнения задач текущего контроля над системой, обеспечение работы СОК, контроль за версиями СПО запуском функций режимов. Примененный принцип централизации управления позволяет минимизировать логику работы системы в целом, облегчает построение «удаленного» управления РЛС (управление с процессоров на которых нет мезонина МПИ и других), в значительной мере облегчает обмен с внешними системами самолета, т.к. не приходится учитывать особенности каждого конкретного режима. Централизованное построение межмодульного обмена исключает возможные коллизии с «наложением» данных при обработке входных и выходных массивов, сбои в диаграмме межмодульного обмена, и гарантирует проведение обмена даже при сбоях и возникновении исключительных ситуациях в функциях режимов. Формирование специфических для каждого режима временных диаграмм выполняется непосредственно в функциях данного режима и не влияет на работу диспетчера. Диспетчер гарантирует синхронный запуск функций режима с частотой тактового импульса или другого события для синхронной работы РЛС и функций режима. Многорежимность каждого диспетчера позволяет иметь на каждом МПД один или несколько функционально независимых режимов по аналогии с БЦВМ-900 или СОЛО-54.

Выполнение задач начального пуска

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

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

Для обеспечения синхронной работы инициализируется программная библиотека обмена событиями. Обмен «событиями» позволяет выполнить синхронизацию задач по установки VI соединений вне зависимости от временных особенностей загрузки каждого МПД обусловленных разной конфигурацией мезонинов.

Инициализация подсистемы VI выполняется на каждом МПД асинхронно, подготавливаются и регистрируются все необходимые буферы и выполняются необходимые действия в соответствии со стандартом VI. Установка VI соединений производится только после получения квитанции от МПД клиента. Модуль ПД-0 выступает всегда в роли СЕРВЕРА для остальных МПД. Соединения между остальными МПД устанавливаются также синхронно. После установки соединений производится подготовка подсистемы VI к информационному обмену.

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

На всех МПД включатся режим «VOID» (нет режима) и производится контроль всех обменов со всеми абонентами на всех магистралях, проверяется соответствие параметров обмена заявленным в протоколах обмена параметрам. Производится ВСК антенны и других блоков, что суммарно не должно превышать 10−15 секунд. Функции режимов во время проведения контроля не вызываются. Производится синхронизация с СОЛО35.01 и анализируются результаты её самоконтроля.

После всех операций диспетчер МПД-0 запускает режим в зависимости от параметров управления полученных вышестоящей системы, и машина переходит в штатный режим работы.

Обработка исключительных ситуаций

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

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

Текущий контроль вычислительной системы и РЛС

Задачи текущего контроля выполняются непосредственно в месте выполнения контролируемого действия. Только так можно обеспечить гарантированный контроль без пропусков возможных кратковременных ошибок. Для каждого контролируемого действия выделяется битовый флаг, показывающий наличие ошибки после выполнения операции и счетчик ошибок. Результаты текущего контроля должны транслироваться режимам для корректировки управления РЛС (если требуется).

Контроль межмодульных обменов является наиболее важной задачей т.к. от этого зависит стабильность системы в целом. Некорректные действия по проведению обмена могут приводить к сбоям во временной диаграмме всех МПД. Это обусловлено особенностями системы межмодульного обмена VI.

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

Контроль параметров входящих линий связи важен для обнаружения «замираний» или полного прекращения выдачи параметров управления и навигационных данных. Для линий МКИО подобный контроль необходим для формирования логики перехода с основного на резервный канал.

Контроль над информационным обменом по шине МПИ между СОЛО35.01 и СОЛО35.02 необходим для формирования признака недостоверности данных. В настоящие время в межмашинном обмене применяются 32(64) разрядные слова с экспоненциальной упаковкой (плавающая точка) разделенные на два 16 разрядных слова МПИ. При возникновении сбоя или разрушения структуры данных на принимающей стороне при любой операции со сбойными словами неминуемо возникнет исключительная ситуация. Корректная обработка признака недостоверности функциями режимов позволит избежать подобной ситуации.

Контроль антенны выполняется по двум критерия: выполнения задач текущего контроля БУЛ, УУП и контроль обменов с этими блоками. Текущий контроль БУЛ и УУП должен выполнятся в процессе их работы без участия управляющей машины. Контроль обменов необходим для выявления потерь данных и выявления непрохождения управления в эти блоки. Подобный контроль значительно облегчит задачу отладки режимов т.к. причина сбоя в работе матобеспечения будет своевременно зарегистрирована. (особенно актуально для режимов с синтезированием апертуры) Контроль над остальными блоками и системами осуществляется в соответствии с их характеристиками.

Для контроля системы оператором данные текущего контроля собираются и упаковываются в соответствии с протоколом и передаются в АРМ для отображения на индикаторе. Критические ошибки немедленно выдаются нВ внешние системы СОК и должны регистрироваться в локальными регистраторами (FREC).

Организация единого информационного пространства, построение межмодульного обмена и переключение режимов работы РЛС с точки зрения вычислительной системы

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

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

Переключение режимов осуществляется тривиальной коммутацией входных информационных потоков, в которых передаются данные необходимые для трансляции в блоки РЛС. Этот подход полностью развязывает режимы между собой и с диспетчером, т.к. каждый режим «управляет» РЛС в рамках своего информационного потока, который он обязан формировать даже в неактивном состоянии. При выполнении этих условий возможно «мгновенное» переключение без потерь тактов, что в данный момент уже реализовано. Логику выбора текущего режима предлагается разместить в диспетчере МПД-0, т.к. это позволит сразу после прихода тактового импульса опросить состояние СОЛО35.01 и с учетом команд управления и особенностей работы конвейерной обработки принять решение о возможности переключения режима. Помимо коммутации информационных потоков диспетчер формирует битовые признаки «ACTIVE» и «STOP», которые сообщает режиму о его активности или фоновой работе. Разрешение на запуск функций режимов во всех МПД разрешается только после успешного завершения всех этапов начального пуска, обеспечивая тем самым подготовку нормального старта системы в условиях сформированного информационного пространства.

Положение функций режимов в единой вычислительной среде

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

Обязательные сервисы, реализуемые в рамках вычислительной системы

Многомодульная система требует ряд сервисов необходимых для полноценного функционирования:

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

«ПК100» — обеспечивает обмен с ПК100, полностью повторяющий работу на СОЛО-54 и БЦВМ900. Разница заключается только в том, что выдача информации на ПК100 выполняется из одного МПД (режима), который является в данный момент активным.

«ПК-СОЛО» — сервис, обеспечивающий просмотр зарегистрированных параметров. Для удобства использования поддерживаются пространства имен. Обмен с персональным компьютером осуществляется по Ethernet.

«FREC» — сервис, обеспечивающий запись зарегистрированных блоков данных на FLASH-память МПД. Сервис предназначен для регистрации данных объективного контроля. Может передавать данные через Ethernet (сервис в процессе разработки).

«СОК» — сервис, обеспечивающий выдачу по РКИО данных во внешний регистратор (УБРП) с любого МПД.

Проектная часть

Цифровая вычислительная система построенная на СЦВМ СОЛО-35.02 и СОЛО-35.01 принципиально отличается от своих предшественников Ц-100, БЦВМ-900, СОЛО-54, БАГЕТ-55 в первую очередь тем, что построена по принципу единой коммутируемой вычислительной среды с независимыми друг от друга модулями и узлами. В этой системе впервые применена для внутреннего межмодульного информационного обмена высокоскоростная последовательная шина PCI-Express, обеспечивающая скорость пересылок типа точка-точка >100МБ/с. В подобной системе полностью исключено нежелательное прямое влияние модулей и программ друг на друга из-за отсутствия общей памяти. С другой стороны усложняется программное обеспечение из-за интеграции в него большого количества всевозможных библиотек для работы с модулями и мезонинами СЦВМ, внутреннего информационного обмена и синхронизации.

Главной особенностью СЦВМ СОЛО-35.02 является наличие 4-х модулей процессоров данных (далее МПД) связанных между собой по шине PCI-E в одном вычислителе, выполняющем роль управляющей ЦВМ в рамках изделия Н135Э. На МПД-0, 1, 4 установлены мезонины, обеспечивающие обмен по МПИ, МКИО и РКИО. В подобной системе в первую очередь приходится решать задачи межмодульной синхронизации, обмена, условного и безусловного распределения данных между модулями, диспетчеризации и текущего контроля. Во вторую очередь выполняются прикладные задачи ФПО реализующие режимы работы РЛС. Вследствие вышесказанного ФПО жестко разделено на системную и не системную части. Системная часть (далее «диспетчер») обеспечивает диспетчеризацию, синхронизацию, текущий контроль, информационное взаимодействие между МПД и с внешними системами, в совокупности с диспетчерами других модулей организует единое информационное пространство. Совокупность программ системного уровня на всех 4-х МПД является Глобальным Диспетчером СОЛО-35.02. Не системная часть (далее «режим») представляет собой набор функций, реализующих режимы работы РЛС и их подрежимы. По сути «режимы» «живут» в среде единого информационного пространства системной части и полностью отвязана от аппаратуры и внешних систем. Взаимодействие между «режимом» и «диспетчером» в рамках одного МПД осуществляется через общие структуры и массивы, обмен между «диспетчерами» (модулями) осуществляется с помощью библиотеки «VI», предоставляющей простой многопотоковый API для организации обмена с любым модулем. Для межмодульной синхронизации используется механизм событий работа с которыми осуществляется с помощью библиотеки «EVTMT».

Модуль процессора данных СОЛО-35.01 по сути является 5-м процессором данных (МПД-А) вычислительной системы, связь с которым осуществляется при помощи общей памяти на шине МПИ. Через МПД-А транслируется управление на МОСы и блоки РЛС управляемые по последовательной шине SMI — Н35−3 и Н35−7. Для повышения устойчивости системы в целом в МПД-А реализован механизм восстановления после сбоев СОЛО-35.01. К сожалению низкая скорость и надежность обмена по шине МПИ не дает реализовать многие возможности, потенциально заложенные в ЦВС.

Из всего вышесказанного делается простой вывод, что данная ЦВС является «многоуровневой» программно-аппаратной системой с множеством последовательных и параллельных «узлов» обработки и распределения информации. Из-за выбранной конфигурации СЦВМ данная система очень плохо резервируется на уровне модулей одной СЦВМ, а резервирование на уровне машин неоправданно дорого. Единственное спасение, на мой взгляд, это применение тотального контроля над системой по принципу каждый контролирует каждого (данный принцип прекрасно ложится на ЕКВС и реализацию программ «диспетчеров» СОЛО-35.02). Контроль над блоками, линиями информационного взаимодействия с внешними в внутренними системами, характеристиками выполнения функций боевых программ, ловушки исключительных ситуаций и парирование ошибок «на лету», организация максимально информативной системы объективного контроля, на мой взгляд, первоочередные задачи разработки системы реального времени для решения радиолокационных задач, особенно если учитывать стоимость испытаний.

Имеющиеся критических ситуации и отказы:

Преждевременный приход и «просечки» тактовых импульсов:

Суть проблемы:

При подаче питания на синхронизатор, включении силовых установок или плохом контакте аппаратура СОЛО-35.02 реагирует на это событие и вызывается обработчик прерывания как при штатном тактовом импульсе. Если ложный импульс возник в момент работы программ МПД-0, то после завершения работы программ МПД-0 снова запустится и разошлет информацию по VI.

Остальные процессоры не готовы её принять и произойдет разрыв VI соединений.

Решение:

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

Пропадание тактовых импульсов:

Суть проблемы:

При отказе синхронизатора, сбоях в его работе или повреждении проводника передачи тактового импульса на СОЛО-35.02 произойдет останов всех МПД и ожидание прихода очередного тактового импульса. (в текущей реализации будут происходить запуски с частотой 0.5Гц необходимые для поддержания системной части ФПО в рабочем состоянии).

Решение:

Организовать выработку прерываний по таймеру с периодом превышающим период тактового импульса на 100 микросекунд. Таймер сбрасывать при приходе очередного ТИ. В обработчике прерываний организовать программный селектор источников прерываний с защитой от двойного срабатывания при восстановлении подачи тактового импульса. (подобный метод поможет сохранить работоспособность СОЛО-35.02 на системном уровне ФПО, а не системы в целом т.к. произойдет рассинхронизация с блоками РЛС).

Отрыв абонента МПИ:

Суть проблемы:

При перезапуске СОЛО-35.01 контроллер МПИ, работающий в режиме SLAVE переходит в начальное состояние и перестаёт отвечать на запросы по магистрали. Контроллер СОЛО-35.02 работающий в режиме MASTER продолжает выполнять обмен с СОЛО-35.01, но каждый цикл обмена завершается по превышению времени ожидания равного 10mks. «Массивный» блочный обмен приводит к сдвигу в конец такта обменов по VI, их наползание на следующий такт и рассинхронизацию между МПД, что приводит к разрыву VI соединений и невозможности продолжения штатной работы.

Решение:

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

Непредвиденный разрыв VI соединений или зависание на ожидании данных от соседнего процессора:

Суть проблемы:

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

Решение:

Библиотека VI в настоящее время содержит ошибку в функциях ожидания приема или отправки данных связанную с ожиданием завершения с заданным ограничением по времени, что приводит к немедленному выходу без ожидания данных. Требуется переход на новую библиотеку и доработка программ «диспетчеров» всех МПД.

1. Зависание МПД-0 при переходе из начального пуска к штатной работе:

Суть проблемы:

При после перехода из начального пуска в штатной работе МПД-0 дважды выводит предупреждение об отсутствии данных от других МПД и зависает. При штатной работе это предупреждение должно выводится только один раз.

Решение:

Встречается крайне редко. В полетах ни разу не проявлялась. На данный момент проблема не решена, т.к. очень сложно её «поймать». Предварительно можно сказать, что это связано с зависанием на ожидании отправки данных по VI (возможно эта проблема связана с библиотекой). Необходимо перейти на новые версии системных библиотек.

Непопадание в V-обмена:

Суть проблемы:

При отрыве провода ИСЧП или нажатии на кнопку «тест» на синхронизаторе происходит «схлопывание» ТИМ-2 и ИСЧП. После этого синхронизатор не реагирует на управление по МПИ, а диспетчер МПД-0 фиксирует непопадание в ТАУ-обмена.

Решение:

При трехкратном непрерывном непопадании в ТАУ-обмена диспетчер МПД-0 запрещает прерывания от ТИМ-1 и выполняет процедуру сброса синхронизатора и «ОЛИВЫ» как в начальном пуске, после чего разрешает прерывания, дожидается прихода первого тактового импульса, выдает управление по расстановке тактовых импульсов на синхронизатор и переходит к штатной работе. После процедуры сброса синхронизатор правильно реагирует на управление.

Рассинхронизация МПД:

Суть проблемы:

При потере широковещательного события или превышении времени выполнения функциями «режима» происходит сдвиг временной диаграммы.

Решение:

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

Зависание или отказ МПД:

Суть проблемы:

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

Решение:

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

Методы вывода из состояний сбоев и парирование ошибок

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

Случаи, когда временная диаграмма замораживается требуют введения единого машинного времени для определения времени «простоя», которое в зависимости от ситуации (типа сбоя) может сильно изменяться.

Все сбои можно разделить на две группы: «тихие» и «громкие».

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

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

Организация текущего контроля ЦВС СОЛО-35 и изделия Н135Э

Контроль внутренних параметров и интерфейсов:

Контроль на стадии начального пуска:

Выполняется однократно при запуске системы. Проверяется структура заполняемая программой «POST» в которой должна находится информация о модулях установленных в крэйт, и результатах встроенного тестирования каждого модуля. На ведущем МПД в данной структуре находится информация о результатах тестирования всех модулей, на остальных МПД только информация о самотестировании.

1.1.2 Проверяется наличие мезонинов в соответствии с заданной конфигурацией СЦВМ. Производится их инициализация и настройка на заданный режим работы с контролем ошибок на каждом этапе инициализации.

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

Контроль состояния VI соединений и межмодульного обмена:

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

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

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

Контроль работы процессоров («перекрестный контроль»):

Выполняется двумя путями: по приходу данных по VI от данного процессора и ответ на событие. В случае невыполнения первого в течении 10 циклов или отсутствия ответа на события процессор считается отказавшим и рекомендуется выполнить полный перезапуск СЦВМ после выдачи на все регистраторы систем объективного контроля информации о произошедшем отказе.

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

Контроль временных характеристик выполняемых программ:

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

Контроль внешних интерфейсов МПД-0:

Выполняется контроль информационного обмена по шине МПИ (мезонин 2Т101 режим) с Н35−6 и СОЛО35.01.

При возникновении ошибок обмена (нет ответа от абонента в течении 10мкс) инкрементируется счетчик ошибок обмена с текущим абонентом и выставляется флаг ошибки на текущий такт. В начале следующего такта флаг сбрасывается.

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

Контроль информационного обмена с БУЛ и УУП по МКИО (мезонин 2Т201 канал 2 режим «Контроллер шины»)

В случае отсутствия ответных слов от БУЛ или УУП в течении 12(14) mks текущее задание считается обработанным с ошибкой, инкрементируется соответствующий счетчик ошибок. На текущий такт выставляется флаг ошибки обмена. Контролируется время завершения последнего задания информационного обмена с БУЛ для выявления выхода из m-обмена (у БУЛ определяется протоколом информационного обмена);

Контроль внешних интерфейсов МПД-1:

Контроль информационного обмена с ИУС по МКИО (мезонин 2Т201 канал 1 режим работы — «Оконечное устройство»);

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

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

Контроль внешних интерфейсов МПД-3:не требуется (мезонины не установлены);

Контроль внешних интерфейсов МПД-4:

Контроль информационного обмена по РКИО с БРЭО (мезонин 2Т001)

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

Для входных линий контролируется период обновления данных (если требуется) по приходу последнего слова пачки в соответствии с протоколом информационного взаимодействия. В случае несоответствия периода обновления данных устанавливается флаг «неверный период»;

Для входных линий прием каждого отдельного слова контролируется по наличию канального адреса в соответствии с протоколом. В случае неверного канального адреса устанавливается флаг «неверное слово», буфер данного слова обнуляется и инкрементируется счетчик ошибочных слов (сбрасывается перед каждым чтением буфера линии);

Контроль тактовых импульсов и временной диаграммы РЛС Контроль параметров внешней синхронизации СЦВМ должен быть многоуровневым для обеспечения максимально возможной защиты. В такой ситуации сбои обусловленные, например, накоплением семафоров становятся невозможными, т.к. каждый ожидающий прихода синхронизации контролирует её параметры;

Первичный контроль должен выполняться в обработчиках прерываний. Необходимо контролировать интервалы между приходом ТИ и «выбрасывать» импульсы пришедшие раннее «критического времени» определяющего время выполнение задач в МПД. Фактически это должно избавить от просечек.

Вторичный контроль должен выполняться программой «диспетчер» на каждом МПД. Контролировать накопления семафоров, период синхрособытий (ТИ или «событие» запуска от МПД-0).

Контроль СОЛО-35.01

Контроль диаграммы информационного обмена по МПИ Помимо п. 4.2.1 необходимо проверять квитанции счетчиков времени СОЛО-35.02 для выявления остановки МПД СОЛО-35.01. Значения счетчиков необходимо регистрировать на внутреннюю СОК для облегчения его обработки совместно с СОЛО-35.01;

Контроль текущего состояния СОЛО-35.01

Должен выполняется по интегральному принципу: только при безошибочном выполнении п. 4.2.1, п. 4.6.1 анализируются признаки «готовность ППС» и «состояние восстановления». При невыполнении п. 4.2.1 и п. 4.6.1 анализ этих признаков не имеет смысла (либо отказ МПИ либо зависание МПД СОЛО35.01);

Признаки состояния и коды ошибок возникающих в СОЛО-35.01 должны транслироваться на все МПД и регистрироваться в СОК;

Контроль БУЛ Контроль обмена по МКИО выполняется в соответствии с п. 4.2.2.1;

Контроль текущего состояния выполняется в соответствии с ТУ на БУЛ;

Контроль Н35−3

Массив слов состояния должен считывается по SMI МПД СОЛО-35.01 и выкладываться в МПИ в соответствующие поля структуры «common_rd»;

Диспетчер СОЛО-35.02 считывает по МПИ структуру и анализирует слова состояния. При наличии отказов производится регистрация на СОК и выставляется признак неисправности блока;

Контроль Н35−5

Прием информации по РКИО выполняется в МПД-4 и передается по VI в МПД-0;

Контроль приема выполнять в callback-функции;

Анализ информации выполняется в МПД-0 и при наличии отказов выставляются их признаки и выполняется запись в СОК;

Контроль Н35−6

Прием информации выполняется в МПД-0 в начале такта при выполнении п. 4.2.1.1;