40
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ А. Астапкович Лекция 8 ВСТРОЕННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ Государственный университет аэрокосмического приборостроения, СПб, 2012

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

  • Upload
    ewa

  • View
    97

  • Download
    0

Embed Size (px)

DESCRIPTION

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. А. Астапкович. ВСТРОЕННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ. Лекция 8. Государственный университет аэрокосмического приборостроения, СПб, 201 2. Встроенные системы управления. СТРУКТУРА –ФУНКЦИИ- COCTAB. выходы. входы. Ns к-во датчиков. Na - PowerPoint PPT Presentation

Citation preview

Page 1: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

А. Астапкович

Лекция 8

ВСТРОЕННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ

Государственный университет аэрокосмического приборостроения, СПб, 2012

Page 2: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

СТРУКТУРА –ФУНКЦИИ-COCTAB

Встроенные системы управления

Page 3: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

КОНТРОЛЛЕР ИЛИ СЕТЬ КОНТРОЛЛЕРОВ

MMIчеловеко-

машинныйинтерфейс

входы: кнопки, клавиатуры, сетевые интерфейсы……

выходы: дисплеи, светодиоды,аудио ……

Ns к-во

датчиков

Na к-во каналов управления

ОБЪЕКТ

входывыходы

ОБОБЩЕННАЯ СТРУКТУРА СИСТЕМЫ УПРАВЛЕНИЯ

  Система управления – это устройство или набор устройств, предназначенных для обеспечения требуемого поведения объекта или объектов управления В общем случае требуется система управления класса MIMO ( Multiple Inputs –Multiple Outputs)

Воздействия среды

Page 4: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Состав системы управления

Система управления включает в себя аппаратную и программные

компоненты.

Наличие аппаратного обеспечения, адекватного по структуре и

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

условием для возможности создания системы управления.

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

система не работоспособна без соответствующего программного

обеспечения.

РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ - ЭТО СЛОЖНЫЙ ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС, ТРЕБУЮЩИЙ СООТВЕТСТВУЮЩЕЙ ОРГАНИЗАЦИИ, ИНСТРУМЕНТАРИЯ И КВАЛИФИЦИРОВАННОГО ПЕРСОНАЛА

Page 5: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

НОРМАЛЬНЫЕ РЕЖИМЫ ЭКСПЛУАТАЦИИ

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

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

системы.

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

Функции системы управления

РЕЖИМЫ С НАРУШЕНИЯМИ НОРМАЛЬНЫХ УСЛОВИЙ ЭКСПЛУАТАЦИИ

АВАРИЙНЫЕ РЕЖИМЫ

Page 6: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

ТЕХНОЛОГИЧЕСКИЕ ЦИКЛЫ РАЗРАБОТКИ

СИСТЕМ УПРАВЛЕНИЯ

Встроенные системы управления

Page 7: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Среднее количество строк исходного кода в приложении выросло с 8 000 в начале 90x до 1 000 000 к 2005 г. И продолжает расти с темпом, определяемым законом Мура. При этом в настоящее время операции тестирования занимают от 50 до 70 процентов от общей трудоемкости по разработке программного обеспечения.

Сам процесс разработки приобретает черты сложного технологического процесса, выполняемого большими коллективами разработчиков.

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

Характеристики техпроцесса

Page 8: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

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

Естественным следствием этого является появление отечественного аналога американского авиационного стандарта DO-178B в виде ГОСТ Р 51904, введенного в действие в 2002 году. Стандарт европейской организации по стандартизации космической

техники ECSS-E-40C представляет собой очередную попытку формализации

процесса разработки программного обеспечения. Этот стандарт идейно совместим

со стандартами DO-178B и ГОСТ Р 51904.

Стандарты разработки ПО

Page 9: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

ГОСТ Р 51904

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

который выполняет в системе отдельную функцию. Компонент представляет собой набор

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

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

программы в символьной форме, например, как исходный код, объектный код или машинный код

Код команды Адреса операндов Параметры

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

В англоязычной литературе и документации этому понятию соответствует “code” или “program code”, которые обозначают программу, представленную в виде набора команд.

ПАМЯТЬ ПРОГРАММ

PC ++

Page 10: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Описание алгоритма

на ассемблере, макроассемблере,

языке С, JAVA

Корректировка

описания алгоритма

модификация алгоритма

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

Отладка с использованием внутрисхемного эмулятора

Трансляция или

компиляция кода,

сборка кода

Отладка с использованием симулятора

Стандартный цикл разработки программного

обеспечения автономного узла

Отладка. Это ключевой элемент цикла разработки систем управления встраиваемого

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

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

Page 11: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

V-модель разработки ПО

Кодирование

Предпроектные исследования,

спецификация требований и

разработка технического задания

Тестирование системы

на приемо-сдаточных испытаниях

Разработка

архитектуры

системы

Интеграция и комплексное

тестирование

системы

Проект

системы

Интеграция и тестирование

программного обеспечения

Проекты

модулей

Тестирование

модулей

Стандарт МЭК 61508 ”Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью”

Page 12: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Спиралеобразная модель разработки полного цикла

Разработка

концепции и

спецификаций

Макетиро-вание

рисков

Тестиро-вание

Разработка и согласование ТЗ на опытный образец

Разработка аппаратной и

программной компонент

Изготовление аппаратной и программных компонент

Системная

интеграция

Автономное тестирование

Комплексное тестирование

Опытная

эксплуатация

Планирование следующей

итерации

Оценка параметров,

ограничений и альтернатив

Оценка реализуемости

требований

Оценка технологических и

финансовых рисков

Макет Опытный

образец

Серийный

образецСтоимость

know-how

Page 13: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

КЛАССИФИКАЦИЯ СПОСОБОВ РАЗРАБОТКИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Page 14: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

ЛИНЕЙНЫЙ ПОДХОД .

Базовый элемент – задача. Алгоритм описывается с использованием ассемблера,

макроассемблера и/или языков С., JAVA

КОМПОНЕНТНОЕ (процедурное) ПРОГРАММИРОВАНИЕ

Базовый элементы: компонент (функция) и библиотеки функций

Алгоритм описывается с использованием ассемблера, языка С, JAVA

Для создания программного кода используются инструментальные

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

ТЕХНОЛОГИИ ОСРВ и mОСРВ

Базовые элементы: нить, процесс, поток

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

ГЕНЕРАТОРЫ ПРИЛОЖЕНИЙ

Базовые элементы: настраиваемое приложение

Описание алгоритма предполагает использование специализированного программного инструментария обслуживающего параметризованное описание алгоритма в составе готового изделия

Маршрут разработки

Down-Up

Маршрут разработки

Up-DOWN

Иерархия методов разработки ПО

Page 15: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Линейный подход.

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

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

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

Page 16: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Компонентное программирование Компонентное или процедурное программирование - это

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

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

собой подпрограмму.

Подпрограмма это набор команд микропроцессора, имеющая собственное имя и

размещаемая в памяти программ по адресу, задаваемому при сборке программного

кода.

Page 17: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

•На ассемблере MPASM фирмы Microchip структура подпрограммы имеет вид: PROC //Cимвольное имя_подпрограммы [Тело подпрограммы: последовательность команд на ассемблере] return //Работа с подпрограммой осуществляется посредством двух команд вызова подпрограммы CALL и возврата RETURN и использует стэк CALL PROC

Механизм реализации

RETURN

PC PC+1

PC<- адрес SUB

PROC PROC1

ПАМЯТЬ ПРОГРАММ

Page 18: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Компонентное программирование, рассматриваемая как технология, существенно

повышает эффективность работы коллектива программистов в смысле

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

обеспечения и стоимости.

Интегральная скорость разработки повышается за счет распараллеливания

процесса разработки, а качество за счет возможности использования

уже проверенных на практике компонент.

Стоимость сокращается за счет уменьшения трудоемкости конечного продукта

Требуется, как минимум, дополнительный инструментарий : редактор связей ( linker) библиотекарь (librarianи более сложная технология разработки, которая

подразумевает документирование процесса, синхронизацию версий, аппаратно-программную совместимость средств разработки.

Преимущества

Page 19: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Введение в операционные системы

Page 20: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Операционная система

ПЕЧАТЬВВОД

ПРОЦЕССОР

ПользовательскийТерминал 1

ПользовательскийТерминал_2

ПользовательскийТерминал_K

ВНЕШНИЕНАКОПИТЕЛЬ_1

СИСТЕМНЫЙТЕРМИНАЛ

ВНЕШНИЕНАКОПИТЕЛЬ _K

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

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

Page 21: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Математический аппарат

ВХОДНОЙ ПОТОКЗАЯВОК НА

ОБСЛУЖИВАНИЕ

Станция обслуживания

ОЧЕРЕДЬ

ВЫХОДНЫЕ ПОТОКИ

Обслуженные заявки

Не обслуженные заявки

Модели систем массового обслуживания (СМО) впервые были разработаны для телефонных станций

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

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

Page 22: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Имитационное моделирование систем

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

Для этого был разработан и широко используется на практике методы имитационного моделирования систем ( пакеты семейства GPSS)

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

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

Page 23: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Задачапользователя

Задачапользователя

Задачапользователя Процессор

ВНЕШНИЕ УСТРОЙСТВА

Память

Диспетчер OC

Управлениеаппаратной

составляющей

MMI

ФУНКЦИИ ОС

ОС обеспечивает для прикладных компонентов необходимые ресурсы вычислительной системы и контролирует процесс его выполнения Ключевые элементы ОС: диспетчер и диспетчер прерываний

Программное обеспечение = операционная система + прикладное ПО

ПАМЯТЬ ПРОГРАММ

Системные компоненты

Прикладной компонент_1

Прикладной компонент_K

Page 24: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

2

1системный компонент; 2 – измерительный компонент по NS каналам;3-вычислительный компонент; 4 – компонент выработки команд управления по NA каналам;

4

2

3

1 1 1 1 1

Tf

A

TT=0 Tс

A0

A1

A2

A3

Многоуровневое описание алгоритмов

Процессограмма модельной системы управления

Page 25: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Пример процессограммы для RR диспетчера

1-й поток

2-й поток

Временной слот Ti

3-й поток

Цикл K Цикл K+1 Цикл K+2 Время

Цикл опроса Tc

очереди задач T Поток

микроядра

Системный вызов диспетчера

Tsys = Tisr+Tdisp

Диспетчеризация

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

Базовые дисциплины диспетчеризации FIFO, RR, RR c приоритетами

Page 26: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

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

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

было возобновить без возникновения ошибок.

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

компонента.

Диспетчер прерываний

СК

К1i К2i Кmi СК

К1 К2 Кm

ПАМЯТЬ ПРОГРАММ

Page 27: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Базовые дисциплины диспетчеризации

Пример процессограммы для RR диспетчера

1-й поток

2-й поток

Временной слот Ti

3-й поток

Цикл K Цикл K+1 Цикл K+2 Время

Цикл опроса Tc

очередиПотокмикроядра

Системный вызов диспетчера

Tsys = Tisr+Tdisp

При переключении с компонента на компонент системные компоненты обеспечивают сохранение и восстановление регистров ( ядра по крайней мере)

Page 28: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

ОСРВ

Page 29: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Системы управления встраиваемого класса

Системы программного управления встраиваемого класса предназначены для обеспечения требуемого поведения управляемого объекта при наличиивнешних возмущающих воздействий

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

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

Основное отличие ОСРВ от ОС заключается в том, что набор и характеристики задач в процессе эксплуатации известны

Page 30: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

КОНТРОЛЛЕР ИЛИ СЕТЬ КОНТРОЛЛЕРОВ

MMIчеловеко-

машинныйинтерфейс

входы: кнопки, клавиатуры, сетевые интерфейсы……

выходы: дисплеи, светодиоды,аудио ……

Ns к-во

датчиков

Na к-во каналов управления

ОБЪЕКТ

входывыходы

ОБОБЩЕННАЯ СТРУКТУРА СИСТЕМЫ УПРАВЛЕНИЯ

  Система управления – это устройство или набор устройств, предназначенных для обеспечения требуемого поведения объекта или объектов управления В общем случае требуется система управления класса MIMO ( Multiple Inputs –Multiple Outputs)

Воздействия среды

Page 31: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Трехканальная система управления

Page 32: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

В соответствии с пунктом 3.2.1 стандарта IEE 610.12:1990 понятие реальное время

(real-time) относится к системе или режиму функционирования, для которого

вычисления выполняются за характерное время внешнего процесса, для того

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

или ответа во временном темпе, определяемым внешним процессом.

Это определение используется и в современной системе европейских

стандартов для аэрокосмических применений.

Часто используют определение:

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

Понятие реального времени.

Page 33: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

На практике используются еще два способа. Спецификации худшего времени выполнения tWCET (WCET - Worst Case Execution Time)

WCET-ACET

Спецификации среднего времени выполнения tACET (ACET -Average Case Execution

Time )

tACET < tWCET < tdeadline

Осталось сделать еще один шаг и признать, что время реакции является вероятностной величиной

Page 34: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Измерение времени Таймерный модуль имеет собственный регистр с разрядностью 2N.

Число, записанное в этот регистр, инкрементируется аппаратно на каждом

командном цикле ( если предделитель отключен). Регистр таймера может инициализируется путем записи в него T0.

При переполнении этого регистра, т. е. при попытке записать в него число равное 2N+1, модуль таймера вырабатывает сигнал прерывания, и ядро микропроцессора осуществляет аппаратную передачу управления на

обработчик прерываний, который считает tic-и

tic [к] = 2N-T0 измерение в tic-ах системного таймера

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

tic [сек] = 1/(f * Nt)( 2N-T0)

Page 35: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

A0

A1

A23 3 3 3 3 3

2

Прерывания от системного таймера

T

2 2 2

На время обработки прерываний от системного таймера производится приостановка выполнения алгоритма, реализуемого компонентом, работа которого была прервана.

Для того, чтобы этот компонент мог после завершения обработки прерывания корректно возобновить реализацию алгоритма в процессе обработки прерывания

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

из прерывания значения этих регистров должны быть восстановлены.

Реализация измерения

Page 36: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

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

Эта структура определяется принятыми соглашениями и моделями базовых объектов.

Она формируется комплексом программно-инструментальных средств IDE с использованием библиотек системных компонентов для работы с базовыми объектами.

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

ОСРВ как технология

Page 37: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Семейство стандартов POSIX надо иметь ввиду при разработке системного программного обеспечения Для ОСРВ наиболее важны семь спецификаций POSIX (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h)

Стандарт POSIX

POSIX-совместимая ОС должна реализовать не менее 32 уровней приоритетов.

POSIX определяет три политики планирования обработки процессов:

SCHED_FIFO – процессы обрабатываются в режиме FIFO и выполняются до завершения,

SCHED_RR – round robin – каждому процессу по очереди выделяется квант времени,

SCHED_OTHER – произвольная дисциплина диспетчеризации, не переносимая на другие платформ

Page 38: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Стандарт 1003.1a (OS Definition) :базовые интерфейсы ОС – поддержку единственногопроцесса, поддержку

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

Стандарт 1003.1b (Realtime Extensions) сигналы реального времени, планирование выполнения (с учетом приоритетов, циклическое планирование), таймеры, синхронный и асинхронный ввод/вывод, ввод/вывод с приоритетами, синхронизация файлов, блокировка памяти,

разделяемая память, передача сообщений, семафоры.

Стандарт 1003.1c (Threads) функции поддержки многопоточной обработки внутри процесса,

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

Page 39: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработан

компанией ARINC в 1997 г.

Этот стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным программным обеспечением .

Стандарт ARINC

В 2003 г. принята новая редакция этого стандарта. ARINC-653. Эта версия в качестве одного из основных требований для ОСРВ в авиации

вводит архитектуру изолированных (partitioning) виртуальных машин.

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

свой собственный раздел.

Page 40: ТЕХНОЛОГИЯ РАЗРАБОТКИ  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ

Распространенные ОСРВ

QNX

QN4

QNX6 (Neutrino)

VxWorks

OSEK/VDK OSEK OS OSEK Time triggered operating system

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