Разработка программы поддержки пользователя СОЛО-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.666666 МГц, U-Таймеры работают на частоте системной шины деленной на 16. На каждом такте внутренний счетчик таймера уменьшается на 1 и при переходе через 0 может вызвать прерывание (в зависимости от настройки). Прерывания от каждого R-Таймера имеют отдельную линию в контроллере прерываний. Прерывания от всех U-Таймеров идут по одной линии в контроллер прерываний. Также имеется 32-х разрядный Watchdog-Таймер, который работает на частоте системной шины - 66.666666 МГц. На каждом такте внутренний счетчик таймера уменьшается на 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-х канальный контроллер мультиплексного канала информационного обмена (МКИО ГОСТ Р 52070-2003) с резервированием. Каждый канал может работать в одном из режимов: «Контроллер шины», «Оконечное устройство» и «Монитор»;
  • Мезонин 2T101 представляет собой контроллер магистрали МПИ (ГОСТ 26765.51-86). Работа возможна в режиме «Задатчик» и «Абонент». Мезонин формирует 8 независимых разовых команд, требующих внешней запитки +27В;
  • Мезонин 2Т001 представляет собой контроллер радиального канала информационного обмена (РКИО ГОСТ 18977-79) и обеспечивает прием по 16 независимым каналам и передачу по 8 независимым каналам. Первые 4 приемных канала и 4 передающих канала могут работать с сигналом «готовность».

Таблица 1

МодульПозиция мезонина 1Позиция мезонина 2МПД-0МПИ 2T101МКИО 2T201МПД-1МКИО 2T201-МПД-3--МПД-4РКИО 2T001-

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


Set CPU multiplier to 12CPU for cache clear ...from SOLOat NS16550 UART's A & B, mode: 115200 8N1is UART Binitialization ... DONEController initialization ... DONESDRAM ... OKimage to RAM ... DONEimage CRC ... OKto RAM ... DONEPCI ... DONEonboard ethernet ... DONENAND 512MB ... DONEYAFFS 16MB boot partition ... DONEPOST - Press ^C for abort! POST: SDRAM=OK NAND=OK PCI=OK PCIE=OK ETH=OKnumber on backplane 0for module registration ... backplane module mask=0000001b PD=0000001b: mac=00:00:00:06:00:16 ip=10.7.10.2 mask=255.0.0.0: mac=00:00:62:70:00:00 ip=7.0.0.1 mask=255.0.0.0: mac=00:00:62:70:00:00 ip=8.0.0.1 mask=255.0.0.0server: 10.7.1.70«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 были выработаны следующие принципы исходя из особенностей многопроцессорной архитектуры единой коммутируемой вычислительной среды:

  1. «Нить» диспетчера в каждом МПД имеет наивысший приоритет среди «нитей» ФПО;
  2. Все функции логики управления и переключения режимов выполняются в контексте диспетчера (централизация управления);
  3. Диспетчеры в каждом МПД должны поддерживать «многорежимность» по аналогии с СОЛО-54;
  4. Переключения режимов в рамках диспетчера должно происходить немедленно после прихода очередного тактового импульса или иного равнозначного события;
  5. Раздача информационных потоков с частотой внешнего тактового импульса или иного события должна выполняться диспетчером;
  6. Межмодульное переключение режимов должно сводится к коммутации информационных потоков от МПД и выполняться диспетчером;
  7. Диспетчеры в каждом МПД должны иметь «EMBCTRL» режим необходимый для выполнения задач начального пуска и встроенного контроля вычислительной системы (не боевых режимов!!!);
  8. Все диспетчеры должны управлять процессом начального пуска каждый в своем МПД и обеспечивать выработку признака интегральной исправности МПД;
  9. Диспетчеры должны контролировать все информационные потоки, приходящие на мезонины, установленные на МПД и проверять их соответствие заданным в протоколах обмена параметрам (темп поступления, количество слов и т.д.);
  10. Диспетчеры должны обеспечивать синхронизацию входящих и исходящих информационных потоков с внешним тактовым импульсом или иным событием и их целостность;
  11. Диспетчер должен управлять обработчиком прерывания от внешнего тактового импульса или обработчиком иного события;
  12. Обработчик прерываний должен иметь фильтр, предотвращающий ложные срабатывания с возможностью динамического изменения параметров фильтра;
  13. Диспетчер должен запускаться при отсутствии тактового импульса или иного события через заданный интервал времени с возможностью динамического изменения интервала;
  14. Диспетчер должен запускать только «нить-100Гц» при разрешении работы режимов с частотой тактового импульса или иного события;
  15. Диспетчер должен контролировать завершение выполнения задач в «нити-100Гц» перед её повторным запуском в целях исключения «накопления» в её семафоре;
  16. Все остальные «нити» режима запускаются из «нити-100Гц» т.к. они полностью принадлежат режиму и не требуются для работы диспетчера;
  17. Все диспетчеры и режимы на всех МПД должны обмениваться информацией только через структуры данных, описанные в общих для всех МПД header-файлах;
  18. Все функции режимов должны быть полностью отвязаны от диспетчера и друг от друга, кроме необходимых для их информационного взаимодействия структур;
  19. Все функции межмодульного обмена выполняются и контролируются в контексте диспетчера и (или) подчиненных только ему вспомогательных «нитях» если таковые требуются;
  20. Все функции обмена с блоками контейнера и внешним БРЭО выполняются и контролируются диспетчером и (или) подчиненных только ему вспомогательных «нитях» если таковые требуются;
  21. Каждый режим должен представляет собой самодостаточный набор функций, который должен включать функцию инициализации и финализации(завершения);
  22. Каждый режим обязан квитировать управление, передаваемое ему диспетчером через общие структуры;
  23. Любой режим обязан немедленно реагировать на изменение управления от диспетчера;
  24. Диспетчер должен обрабатывать исключительные ситуации, возникающие в процессе работы режимов (реакция диспетчера на исключительную ситуацию должна быть утверждена главным конструктором);
  25. Диспетчер данного МПД должен сообщать всем диспетчерам системы о возникновении исключительной ситуации в выполняемом режиме в целях предотвращения возникновения исключительной ситуации в других МПД по причине возможной недостоверности передаваемых из режима данных;
  26. Диспетчер имеет право «перекоммутировать» информационные потоки с режима на себя в целях сообщения во внешние системы о возникновении исключительной ситуации (запись в СОК);
  27. Каждый диспетчер должен иметь ряд «подсистем» необходимых для облегчения разработки программ режима и контроля его работы: «удаленная запись по шине МПИ», «СОК», «ПК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;

В первую очередь должен проверяется отсутствие ошибок обмена и попадание в обмена (если не попали смотри п.2.6);

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

Контроль Н35-7

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

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


Контроль состояния вычислительной системы на АРМ


1.Структуры и массивы информации управления блоками РЛС, информационного обмена с вышестоящими системами и системного контроля должны передаваться со всех МПД в МПД-0 СОЛО-35.02;

2.Информация п.5.1 должна собираться по команде от АРМ после прихода данных от активного МПД в МПД-0 и передаваться в АРМ по Ethernet;

.Критические параметры должны быть доступны для контроля сервиса ПК-СОЛО;

.На АРМ должна быть возможность записи контролируемой информации в файл на жесткий диск;

.Для контроля информации на АРМ должна быть программа просмотра зарегистрированного файла или просмотра информации «на лету», по мере поступления из СОЛО-35.02;

6.Протокол информационного взаимодействия между глобальным «диспетчером» СОЛО-35.02 и функциями режимов в части информации текущего контроля и сбойных ситуаций

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

2.В случае разрыва «VI» соединения или невозможности получения данных все поля структуры относящиеся к не полученным данным выставляются в состояние «неисправность»;

.Структура данных находится в процессе разработки;

Протокол обмена информацией о сбоях между СОЛО-35.01 и СОЛО-35.02

1.обмен выполнять в начале каждого такта по шине МПИ;

2.после успешного выполнения п.4.2.1 считывать состояние СОЛО-35.01 и помещать полученные данные в структуру типа exch_common_rd_t:


typedef struct

{counter; /* Счетчик тактов */revision; /* Версия таблицы обмена (XCHG_REVISION) */

/* ----- Исправность СОЛО 35.01 ---- */error_code; /* Код ошибки СОЛО 35.01 */error_code_ex; /* Расширение кода ошибки СОЛО 35.01 */

/* ----- Исправность Н35-3 ---- */n3_macp_summ_kk; /* Слово исправности МАЦП сумм, КК */n3_macp_az_um; /* Слово исправности МАЦП Аз, УМ */n3_macp_svr; /* Слово исправности МАЦП СВР */n3_module; /* Слово исправности модуля сопряжения */n3_mupch_summ_kk; /* Слово исправности МУПЧ сумм, КК */n3_mupch_az_um; /* Слово исправности МУПЧ Аз, УМ */

/* ----- Исправность Н35-7 ---- */n7_code; /* Слово исправности бл. Н35-7 */restore_state; /*

р. - 1: ППС свободен (переключение разрешено)

: ППС занят (накопление или обработка)

р. - состояние восстановления

*/reason; /* причина перехода в восстановление */source; /* источник перехода в восстановление */

} xchg_common_rd_t;


Протокол регистратора текущего контроля СОЛО-35.02

1.Регистрация параметров работы вычислительной системы должна производиться с частотой прихода синхроимпульса (ТИ);

2.В случаях возникновения критических ситуаций регистрацию на встроенную СОК выполнять немедленно, на УБРП выдавать короткий набор, перебивая наборы выдаваемые функциями «режимов»;

3.Структура данных находится в процессе разработки;

Протокол СОК УБРП по регистрации системных событий и сбоев

1.Требуется не менее 3-х наборов для выдачи в СОК УБРП (выделены наборы 6, 8, 9);

2.Выдача СОК в УБРП должна производится сразу после запуска СЦВМ и содержать подробную информацию о процессе запуска: инициализации модулей, установления соединений «VI», результаты встроенных тестов, тестов начального пуска и т.д.;

.Структура данных находится в процессе разработки;



Экономическая часть


В этом курсовом проекте решается задача разработки программы «Диспетчер». В текущем разделе определяются оптимальные сроки и затраты на разработку и изготовление ФПО «Диспетчер».

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

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

Основными элементами сетевого графика являются работа и событие. Работа на сетевом графике изображается стрелками. Термин "работа" имеет несколько значений:

·действительная работа - это трудовой процесс, требующий затрат времени и ресурсов;

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

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

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

Для подсчета оплаты труда использовались данные таблице.


Таблица. Продолжительность работ.

Определение работыИсполнителиТрудоемкость, часОклад, руб./часЗП, руб.ДолжностьКол-воАнализ заданияИнженер 1 к.140451800Разработка структурной схемыИнженер 1 к.140451800Разработка ПОИнженер 1 к.14204518900Разработка принципиальной электрической. схемыИнженер 1 к.150452250Разработка документацииИнженер 1 к.150452250Оформление заявки на покупные изделия и материалыИнженер 1 к150452250Получение покупных изделий и материаловЛаборант12030600Передача покупных изделий и материалов в цехИнженер 1 к.1645270Передача документации в цехИнженер 1 к.1645270Изготовление опытного образцаСлесарь1641246Монтажник1638228Лаборант1630180Испытание опытного образцаИнженер 1 к.11245540Настройка опытного образцаИнженер 1 к.1100454500Корректировка документацииИнженер 1 к.130451350Итого84237434

Таблица Оклады работников

Должность исполнителяОкладИнженер 1-ой категории12500Слесарь 6 разряда11000Монтажник 6 разряда10000Лаборант8000

Расчет затрат на создание ФПО


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

Полный фонд заработной платы определим по формуле:


Фз.п. = (1+0,5)* 37434 = 56151 руб.


Дополнительная заработная плата за непроработанное время рассчитывается как сумма отчислений на оплату отпусков, бюллетеней и т.д. На практике составляет 10-15% от основной заработной платы.

Дополнительную заработную плату определим по формуле:


Здоп. =Фз.п.*0,15 = 8422,65 руб.



Фонд оплаты труда определяется, как сумма полного фонда заработной платы и дополнительной заработной платы:


Фо.т. =Фз.п. + Здоп. = 64573,65 руб.


Расходы на командировки отсутствуют.

Начисления на основную и дополнительную заработные платы, устанавливаемые на федеральном уровне, составляют:

в пенсионный фонд - 20%;

в фонд обязательного медицинского страхования - 3,1%;

в фонд обязательного социального страхования - 2,9%;

страховой взнос - 0,2%.

Начисления на фонд оплаты труда:


Начисл. = (0,2+0,031+0,029+0,002)*Фо.т. = 16918,3 руб.


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

Накладные расходы составят:


Знак.расх. = 1.32*Фо.т. = 85237 руб.



Затраты на изготовление опытного образца


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

Полная стоимость затрат на материалы составила:


Зм. = 42 руб.


Общие затраты на комплектующие изделия приведены в таблице и составили:


Зк.и. = 22490 руб.


Стоимость прочих готовых изделий составляет 10% от стоимости комплектующих изделий:


Зпр. = 0,1 * Зк.и. = 2249 руб.


Транспортно-заготовительные расходы составляют 3% от стоимости комплектующих изделий:


Рт.з. = 0,03 * Зк.и. = 674,7 руб.


Общие затраты на материалы и комплектующие изделия, как сумма всех расходов:



Зобщ. = Зм. + Зк.и. + Зпр. + Рт.з. = 25455,7 руб.


Таблица Затраты на материалы

Наименование материалаМаркаЕдиница измеренияРасход материалаЦена за единицу, руб.Сумма затрат, руб.1. ПроводПЭВ -КТ-2Мм2242. ЛакЭП9114кг0,2100203. ПрипойПОС-61кг0,250104. Канифолькг0,103035. Спиртл0,1505Итого42

Таблица Затраты на покупные комплектующие изделия

НаименованиеКол-во, шт.Цена, руб.Сумма затрат, руб.Микросхемы74HC24511010ЧИП-дроссель типоразмер 0805 BLM21BD222TN1D11010EP3C16Q240120002000EPCS41100100MAX9991300300SN74CBTD3861PW635210SN65LVDS0475100500SN65LVDS048580400SN74ABT1262816LVС4245620120РезисторыРезисторная сборка CAT16-100J4 4x10 Oм154600805 180 Ом310100805 0 Ом (перемычка)210100603 1 кОм310100603 4.7 кОм510100603 10 кОм151150603 33 Ом3130603 100 Ом182360603 110 Ом1220603 150 Ом1220603 200 Ом122,5300603 390 Ом33399Подстроечный резистор 3314G-1-103E 10 кОм15050КонденсаторыКерамический конденсатор типоразмер 0603 0.1мкФ10261012Керамический конденсатор типоразмер 0603 10пФ4824Танталовый конденсатор типоразмер D 47мкФ440160Танталовый конденсатор типоразмер D 100мкФ470280Танталовый конденсатор типоразмер D 68мкФ1220240Танталовый конденсатор типоразмер D 220мкФ1150150СтабилизаторыLM1084-3.316060LM1084-ADJ14040LP3893ES-1.21150150LT1963AEST-2.51130130РазъемыDHR78-F1600---IDC10M2816IDC20M21836IDC64M13030PLD-2x1488PLD-3x131010SMA1150150THP-4MR130---ПрочееСветодиод типоразмер 08055420Кварцевый генератор KXO-V97 50.0 MHz1140140Диод BAT54S41560Тактовая кнопка4312Корпус150005000Печатная плата160006000Итого17731

Расчет цены изделия


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

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

Сполн. = Фо.т. + Начисл. + Знак.расх. + Зобщ. = 127611 руб.

Установим предполагаемую прибыль от продажи МФПК на отметке 20% от полной себестоимости изготовления опытного образца.

Затраты на проведение работ сторонними организациями не учитываем.

Прибыль составит:


Прибыль = Кприб. *·Сполн. = 25522,2 руб.


Стоимость МФПК составит:


СМФПК = Сполн. + Прибыль = 153133,2 руб.


Учитывая, что НДС (18%), определим общую цену устройства с учетом НДС.

Цена МФПК составит:


Цэб = СМФПК *(1+0,18) = 180697,2 руб.


Итак, итоговая цена МФПК составит - 180697,2 руб.

Соответствующие статьи расходов приведены в таблице.


Таблица Сводная итоговая таблица.

Статья расходаНормативСумма, руб.1. Материальное обеспечениеМатериалы42Комплектующие17731Итого материальное обеспечение177732. Расходы на оплату труда (РОТ)Основная ЗП56151Дополнительная ЗП8422,65Итого фонд оплаты труда64573,653. Отчисления по оплате трудаВ фонд соц. страхования0,0291872,65В пенсионный фонд0,2012914,73В фонд медиц. страхования0,0312001,78Страховой взнос0,002129,15Итого отчисления16918,314. Накладные расходы852375. Расходы на командировку-6. Прочие расходы-7. Расходы на работу сторонних организаций-8. Полная себестоимость1276119. Начисленная прибыль0,225522,210. Стоимость153133,211. Налог на добавочную стоимость0,1827563,9812. Цена162133,27

Обеспечение безвредных условий труда и информационной безопасности при разработке ПО


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

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

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

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

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

Работники ВЦ сталкиваются с воздействием таких физически опасных и вредных производственных факторов, как: повышенный уровень шума, повышенная температура внешней среды, отсутствие или недостаток естественного света, недостаточная освещенность рабочей зоны, электромагнитное излучение, электрический ток, статическое электричество и др. Многие специалисты по ИТ связаны с воздействием таких психофизиологических факторов, как умственное перенапряжение, перенапряжение зрительных и слуховых органов, монотонность труда, эмоциональные перегрузки. Воздействие указанных неблагоприятных факторов приводит к снижению работоспособности, вызываемому развивающимся утомлением. Появление и развитие утомления связано с изменениями, возникающими в процессе работы в центральной нервной системе, с тормозными процессами в коре головного мозга. Например, сильный шум вызывает трудности в распознавании цветовых сигналов, снижает быстроту восприятия цвета, остроту зрения, зрительную адаптацию, нарушает восприятие визуальной информации, снижает способность быстро и точно выполнять координированные движения, уменьшает на 5-12% производительность труда. Длительное воздействие шума с уровнем звукового давления 90 дБ снижает производительность труда на 30-60%.

Поэтому задачу данной работы можно сформулировать так - обеспечение безвредных условий труда.


Требования к помещению


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

Для обеспечения нормальных условий труда санитарные нормы [1] устанавливают на одного работающего объем производственного помещения не менее 15 м2, площадь помещения выгороженного стенами или глухими перегородками не менее 4,5 м2 при высоте потолка не менее 3,3 м. Полы в помещении должны быть выполнены из негорючих материалов и удовлетворять гигиеническим, технологическим и эксплуатационным требованиям [2].


Требования к микроклимату


С целью создания нормальных условий для персонала ВЦ установлены нормы производственного микроклимата [3]. Эти нормы устанавливают оптимальные и допустимые значения температуры, относительной влажности и скорости движения воздуха помещений ВЦ.

На организм человека, работающего на компьютере, большое влияние оказывает относительная влажность воздуха. При влажности воздуха до 40 % становится хрупкой основа магнитной ленты, повышается износ магнитных головок, выходит из строя изоляция проводов. При относительной влажности воздуха более 75 - 80 % снижается сопротивление изоляции, изменяются рабочие характеристики ЭВМ, возрастает интенсивность отказов элементов машины.

С целью обеспечения комфортных условий для обслуживающего персонала и надежности технологического процесса в ВЦ [4] устанавливают требования к воздушной среде помещений ВЦ: температура воздуха 18 - 22 градусов, относительная влажность 50 - 70 %, скорость движения воздуха не более 0,3 м/с.

В помещении ВЦ необходимо предусматривать систему отопления. Она должна обеспечить достаточное, постоянное и равномерное нагревание воздуха в помещениях в холодный период года. При этом колебания температуры в течение суток не должны превышать 2 - 3 градуса; в горизонтальном направлении - 2 градуса на каждый метр длины, а в вертикальном - 1 градус на каждый метр высоты помещения.

Атмосферное давление в помещениях ВЦ должно быть 1013,25±266 ГПа. При пониженном давлении воздуха ухудшается отвод теплоты от ЭВМ, снижаются изоляционные свойства воздуха.

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

В помещении, где находится компьютер, необходимо обеспечить приток свежего воздуха, количество которого определяется технико-экономическим расчетом и выбором схемы системы вентиляции. Минимальный расход воздуха определяется из расчета 50 - 60 м3/ч на одного человека, но не менее двукратного воздухообмена в час.

Вентиляционные установки должны включаться до начала работы и выключаться после их окончания. Состав воздуха необходимо поддерживать в соответствии с оптимальным. Запыленность помещения не должна превышать 0,5 мг/м3, что достигается кондиционированием.





Заключение


При написании дипломной работы ставилась задача разработки программы поддержки пользователя СОЛО-35.01 и СОЛО-35.02. Сначала проводился анализ методов решения задачи. Далее разрабатывалась аппаратная структура и программное обеспечение ФПО. Приведено описание компонентов ФПО СОЛО-35.01 и СОЛО-35.02.

В экономической части дипломной работы произведен расчет стоимости разработки аппаратуры и программного обеспечения ФПО СОЛО-35.01 и СОЛО-35.02 и ее изготовления.




Литература


.Библиотека Сетевой Безопасности (#"justify">."Кресло человека оператора. Общие эргономические требования", ГОСТ 21889 76.

3.Сайт компании Internet Security Systems (#"justify">4.Журнал "Компьютерра" (htth://www.computerra.ru), №78, 2005.

."Искусство схемотехники", Хоровиц П., Хилл У., Москва "Мир", 1998

6."Embedded Software Development with eCos", Anthony J.Massa, 2002

7."Cyclone Device Handbook", 2003

.«Полный справочник по С» 4-е издание. Герберт Шилдт, 2002


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

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ