Лекция 8. Технология разработки программного обеспечения

advertisement
ВСТРОЕННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ
Лекция 8
ТЕХНОЛОГИЯ РАЗРАБОТКИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
А. Астапкович
Государственный университет аэрокосмического приборостроения, СПб, 2012
Встроенные системы управления
СТРУКТУРА –ФУНКЦИИ-COCTAB
ОБОБЩЕННАЯ СТРУКТУРА СИСТЕМЫ УПРАВЛЕНИЯ
Воздействия среды
выходы
Na
к-во каналов
управления
входы
Ns
к-во
датчиков
ОБЪЕКТ
КОНТРОЛЛЕР ИЛИ СЕТЬ КОНТРОЛЛЕРОВ
входы:
кнопки, клавиатуры,
сетевые интерфейсы……

MMI
человекомашинный
интерфейс
выходы:
дисплеи, светодиоды,
аудио ……
Система управления – это устройство или набор устройств, предназначенных
для обеспечения требуемого поведения объекта или объектов управления
 В общем случае требуется система управления класса MIMO
( Multiple Inputs –Multiple Outputs)
Состав системы управления
Система управления включает в себя аппаратную и программные
компоненты.
Наличие аппаратного обеспечения, адекватного по структуре и
составу функциям системы управления, является необходимым
условием для возможности создания системы управления.
Однако даже идеально спроектированная с аппаратной точки зрения
система не работоспособна без соответствующего программного
обеспечения.
РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ - ЭТО СЛОЖНЫЙ
ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС, ТРЕБУЮЩИЙ СООТВЕТСТВУЮЩЕЙ
ОРГАНИЗАЦИИ,
ИНСТРУМЕНТАРИЯ
И
КВАЛИФИЦИРОВАННОГО
ПЕРСОНАЛА
Функции системы управления
 НОРМАЛЬНЫЕ РЕЖИМЫ ЭКСПЛУАТАЦИИ
Система управления реального времени встраиваемого класса должна
обеспечивать выработку управляющих воздействий на основании задаваемого
режима управления и обработки показаний датчиков о состоянии системы.
Принципиально важным является необходимость обеспечения сбора
данных и выработки управляющих воздействий по многим каналам со
специфицированными временными параметрами, обеспечивающими
актуальность данных и воздействий.

РЕЖИМЫ С НАРУШЕНИЯМИ НОРМАЛЬНЫХ УСЛОВИЙ ЭКСПЛУАТАЦИИ
 АВАРИЙНЫЕ РЕЖИМЫ
Встроенные системы управления
ТЕХНОЛОГИЧЕСКИЕ ЦИКЛЫ
РАЗРАБОТКИ
СИСТЕМ УПРАВЛЕНИЯ
Характеристики техпроцесса
Среднее количество строк исходного кода в приложении выросло с 8 000 в
начале 90x до 1 000 000 к 2005 г. И продолжает расти с темпом,
определяемым законом Мура.
При этом в настоящее время операции тестирования занимают от 50 до 70
процентов от общей трудоемкости по разработке программного обеспечения.
Сам процесс разработки приобретает черты сложного
технологического процесса, выполняемого большими коллективами
разработчиков.
Как следствие, это приводит к специализации функций и регламентации
базовых этапов и операций.
Стандарты разработки ПО
Формализация применяемых процедур тестирования и привязка их к
международным стандартам является одним из ключевых условий
возможности
организации
международной
кооперации
в
аэрокосмической сфере.
Естественным следствием этого является появление отечественного
аналога американского авиационного стандарта DO-178B в виде ГОСТ Р
51904, введенного в действие в 2002 году.
Стандарт европейской организации по стандартизации космической техники
ECSS-E-40C представляет собой очередную попытку формализации процесса
разработки программного обеспечения. Этот стандарт идейно совместим со
стандартами DO-178B и ГОСТ Р 51904.
ГОСТ Р 51904
Алгоритм
Конечное множество четко определенных правил, которые задают
последовательность действий при выполнении конкретной задачи.
Компонент Представляет собой замкнутую часть, комбинацию или элемент, который
выполняет в системе отдельную функцию. Компонент представляет собой набор команд,
оформленный в соответствии с правилами, определяемыми используемым программным
инструментарием.
Программный код. Способ реализация конкретных данных или конкретной компьютерной
программы в символьной форме, например, как исходный код, объектный код или машинный код
 В англоязычной литературе и документации этому понятию соответствует “code” или
“program code”, которые обозначают программу, представленную в виде набора команд.
 Команда представляет собой битовую строку, состоящую из нескольких
программный код набор линейно упорядоченных команд
Код команды
Адреса операндов
Параметры
PC ++
ПАМЯТЬ ПРОГРАММ
полей, а
Стандартный цикл разработки программного
обеспечения автономного узла
Описание алгоритма
на ассемблере,
макроассемблере,
Трансляция или
компиляция кода,
сборка кода
языке С, JAVA
Корректировка
описания алгоритма
Отладка с
использованием
симулятора
Прошивка кода в макет
устройства или в опытный
образец
модификация алгоритма
Отладка с использованием
внутрисхемного эмулятора
Отладка. Это ключевой элемент цикла разработки систем управления встраиваемого
класса, заключающийся в проверке возможности обеспечения специфицированных
параметров на макете или опытном образце системы при использовании текущей
версии программного обеспечения.
V-модель разработки ПО
 Стандарт МЭК 61508 ”Функциональная безопасность систем электрических, электронных,
программируемых электронных, связанных с безопасностью”
Предпроектные исследования,
Тестирование системы
спецификация требований и
на приемо-сдаточных
испытаниях
разработка технического задания
Разработка
Интеграция и комплексное
архитектуры
тестирование
системы
системы
Проект
Интеграция и тестирование
системы
программного обеспечения
Проекты
Тестирование
модулей
модулей
Кодирование
Спиралеобразная модель разработки полного цикла
Оценка параметров,
Оценка технологических и
ограничений и
альтернатив
финансовых рисков
Изготовление
аппаратной и
программных
компонент
Разработка
аппаратной и
программной
компонент
Разработка
концепции и
спецификаций
Стоимость
Разработка и
согласование ТЗ на
опытный образец
Макетирование
рисков
Макет
know-how
Опытный
Серийный
образец
образец
Системная
Тестирование
интеграция
Автономное
тестирование
Опытная
эксплуатация
Комплексное
тестирование
Планирование следующей
Оценка реализуемости
итерации
требований
КЛАССИФИКАЦИЯ
СПОСОБОВ РАЗРАБОТКИ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Иерархия методов разработки ПО
Маршрут
разработки
Up-DOWN
ГЕНЕРАТОРЫ ПРИЛОЖЕНИЙ
Базовые элементы: настраиваемое приложение
Описание алгоритма предполагает использование специализированного
программного инструментария обслуживающего параметризованное
описание алгоритма в составе готового изделия
ТЕХНОЛОГИИ ОСРВ и mОСРВ
Базовые элементы: нить, процесс, поток
Описание алгоритма предполагает использование специализированной
структуры программного обеспечения, специализированных библиотек и
специализированной IDE
КОМПОНЕНТНОЕ (процедурное) ПРОГРАММИРОВАНИЕ
Базовый элементы: компонент (функция) и библиотеки функций
Алгоритм описывается с использованием ассемблера, языка С, JAVA
Для создания программного кода используются инструментальные
программы обслуживания библиотек и сборки программного кода
ЛИНЕЙНЫЙ ПОДХОД .
Базовый элемент – задача. Алгоритм описывается с использованием ассемблера,
макроассемблера и/или языков С., JAVA
Маршрут
разработки
Down-Up
Линейный подход.
Линейный подход
использует описание алгоритма с простой
структурой и на практике применим для систем управления с
небольшим количеством каналов управления.
Для описания алгоритмов, реализуемых с помощью линейного подхода,
используются стандартные блок-схемы. Коды, реализуемые только на
ассемблерах плохо обозримы.
Для увеличения обозримости кода в настоящее время широкое используют
как синтаксис, так и собственно язык С для написания модулей.
Как правило, описание алгоритма выполненное на С транслируется
компилятором в описание на языке ассемблера. При этом естественным
образом обеспечивается возможность использования ассемблерных вставок.
Компонентное программирование
Компонентное или процедурное программирование - это способ разработки
программных кодов с широким использованием предварительно разработанных
компонент. Разработка компонент может вестись как ассемблере, так и на языках
Высокого уровня
Используется специализированные библиотек (например BSP), поставляемых
разработчиками электронных компонент, внутрифирменных библиотек и
библиотек компонент текущего проекта.
При программировании на ассемблере минимальный компонент представляет
собой подпрограмму.
Подпрограмма это набор команд микропроцессора, имеющая собственное имя и
размещаемая в памяти программ по адресу, задаваемому при сборке программного
кода.
Механизм реализации
•
На ассемблере MPASM фирмы Microchip структура подпрограммы имеет вид:
PROC
//Cимвольное имя_подпрограммы
[Тело подпрограммы: последовательность команд на ассемблере]
return
//
Работа с подпрограммой осуществляется посредством двух команд
вызова подпрограммы CALL и возврата RETURN и использует стэк
CALL PROC
PC<- адрес SUB
PC PC+1
ПАМЯТЬ ПРОГРАММ
PROC
RETURN
PROC1
Преимущества
Компонентное программирование, рассматриваемая как технология, существенно
повышает эффективность работы коллектива программистов в смысле
интегральной скорости разработки, качества создаваемого программного
обеспечения и стоимости.
Интегральная скорость разработки повышается за счет распараллеливания
процесса разработки, а качество за счет возможности использования
уже проверенных на практике компонент.
Стоимость сокращается за счет уменьшения трудоемкости конечного продукта
Требуется, как минимум, дополнительный инструментарий :
 редактор связей ( linker)
 библиотекарь (librarian
и более сложная
технология разработки, которая подразумевает
документирование процесса, синхронизацию версий, аппаратно-программную
совместимость средств разработки.
Введение в операционные системы
Операционная система
Берет свое начало от вычислительных центров коллективного
пользования
и представляет собой
специализированное
программное обеспечение
Пользовательский
Терминал 1
Пользовательский
Терминал_2
Пользовательский
Терминал_K
СИСТЕМНЫЙ
ТЕРМИНАЛ
ПРОЦЕССОР
ВВОД
ВНЕШНИЕ
НАКОПИТЕЛЬ_1
ВНЕШНИЕ
НАКОПИТЕЛЬ _K
ПЕЧАТЬ
Базовые функции :
 обеспечение интерфейсов с внешними устройствами
 предоставление ресурсов пользовательской программе
 обработка сбойных ситуаций
Математический аппарат
Модели систем массового обслуживания
разработаны для телефонных станций
(СМО)
впервые
были
ВЫХОДНЫЕ ПОТОКИ
ВХОДНОЙ ПОТОК
ЗАЯВОК НА
ОБСЛУЖИВАНИЕ
ОЧЕРЕДЬ
Станция
обслуживания
Обслуженные
заявки
Не обслуженные
заявки
Время поступления заявок, их время обслуживание заявки являются случайными,
соответственно этому, анализ систем проводится вероятностными методами
Аналитические решения ряда ключевых параметров таких систем были получены
для одноканальных систем с отказами и систем с ожиданием для канонических
форм входного потока: потоки Эрланга, Пуассона и .т.п.
Имитационное моделирование систем
Появление вычислительных машин существенно расширило возможность
моделирования поведения сложных многоканальных систем со сложной
структурой станции обслуживания
Для этого был разработан и широко используется на практике методы
имитационного моделирования систем ( пакеты семейства GPSS)
Эти методы базируются на проведении численного эксперимента с моделью
системы, описанием входного потока заявок, принятыми дисциплинами
обслуживания, как входных очередей заявок, так и самих заявок
Как правило, интерес представляет вероятность отказа в обслуживании,
среднее время нахождения заявки в очереди, вероятности отсутствия заявок
на каком-либо элементе станции обслуживания
ФУНКЦИИ ОС
Программное обеспечение = операционная система + прикладное ПО
Задача
пользователя
Задача
пользователя
Задача
пользователя
Управление
аппаратной
составляющей
Диспетчер
OC
ВНЕШНИЕ
УСТРОЙСТВА
Процессор
Память
MMI
ОС обеспечивает для прикладных компонентов необходимые ресурсы вычислительной
системы и контролирует процесс его выполнения
Ключевые элементы ОС: диспетчер и диспетчер прерываний
Системные
компоненты
Прикладной
компонент_1
ПАМЯТЬ ПРОГРАММ
Прикладной
компонент_K
Многоуровневое описание алгоритмов
A
A0
A1
1
1
1
1
1
2
2
A2
3
A3
4
T=0
Tf
Tс
1системный компонент; 2 – измерительный компонент по NS каналам;
3-вычислительный компонент; 4 – компонент выработки команд управления по NA каналам;
Процессограмма модельной системы управления
T
Диспетчеризация
Диспетчер (sheduler). Представляет собой системный компонент, обеспечивающий
порядок обработки информации в многоканальных системах управления, путем запуска
соответствующих прикладных компонент кода.
Запуск компонента на выполнение
подразумевает выделение ему требуемых ресурсов ( память, процессор и периферия)
Базовые дисциплины диспетчеризации FIFO, RR, RR c приоритетами
Цикл опроса
Tc очереди
задач T
Системный вызов
диспетчера
Tsys = Tisr+Tdisp
Поток
микроядра
1-й поток
2-й поток
3-й поток
Цикл K
Временной слот
Цикл K+1 Ti
Цикл K+2
Пример процессограммы для RR диспетчера
Время
Диспетчер прерываний
Одной из важнейших функций диспетчера является обеспечения ресурсами
компонент, обрабатывающими сигналы прерываний.
При этом требуется обеспечить корректную приостановку процесса реализации
текущей задачи с тем, чтобы после обработки сигнала прерывания, его можно было
возобновить без возникновения ошибок.
При этом не следует забывать о необходимости
выполнять временные ограничения по времени выполнения прерванного компонента.
СК
К1i
К2i
Кmi
СК
К1
ПАМЯТЬ ПРОГРАММ
К2
Кm
Базовые дисциплины диспетчеризации
Цикл
опроса Tc
очереди
Системный вызов диспетчера
Поток
микроядра
Tsys = Tisr+Tdisp
1-й поток
2-й поток
3-й поток
Временной слот Ti
Цикл K
Цикл K+1
Цикл K+2
Время
Пример процессограммы для RR диспетчера
При переключении с компонента на компонент системные компоненты
обеспечивают сохранение и восстановление регистров ( ядра по крайней мере)
ОСРВ
Системы управления встраиваемого класса
Системы программного управления встраиваемого класса предназначены
для обеспечения требуемого поведения управляемого объекта при наличии
внешних возмущающих воздействий
Базовый цикл : измерение-обработка-выдача управляющих воздействий
Требуется обеспечить его реализацию с заданными временными
параметрами для многоканальных систем при наличии информационного
обмена между каналами и их взаимного влияния друг на друга
Основное отличие ОСРВ от ОС заключается в том, что набор и
характеристики задач в процессе эксплуатации известны
ОБОБЩЕННАЯ СТРУКТУРА СИСТЕМЫ УПРАВЛЕНИЯ
Воздействия среды
выходы
Na
к-во каналов
управления
входы
Ns
к-во
датчиков
ОБЪЕКТ
КОНТРОЛЛЕР ИЛИ СЕТЬ КОНТРОЛЛЕРОВ
входы:
кнопки, клавиатуры,
сетевые интерфейсы……

MMI
человекомашинный
интерфейс
выходы:
дисплеи, светодиоды,
аудио ……
Система управления – это устройство или набор устройств, предназначенных
для обеспечения требуемого поведения объекта или объектов управления
 В общем случае требуется система управления класса MIMO
( Multiple Inputs –Multiple Outputs)
Трехканальная система управления
Понятие реального времени.
В соответствии с пунктом 3.2.1 стандарта IEE 610.12:1990 понятие реальное время
(real-time) относится к системе или режиму функционирования, для которого
вычисления выполняются за характерное время внешнего процесса, для того
чтобы результат вычислений мог быть использован для управления, мониторинга
или ответа во временном темпе, определяемым внешним процессом.
Это определение используется и в современной системе европейских
стандартов для аэрокосмических применений.

Часто используют определение:
системы управления реального времени – это такие системы, у которых
время реакции на внешнее воздействие
не
превышает
специфицированного по каждому из каналов управления/воздействия,
обозначаемое как tdeadline.
WCET-ACET
На практике используются еще два способа.
Спецификации худшего времени выполнения
tWCET
(WCET - Worst Case Execution Time)
Спецификации среднего времени выполнения
tACET
(ACET -Average Case Execution Time )
tACET < tWCET < tdeadline
Осталось сделать еще один шаг и признать, что время реакции
является вероятностной величиной
Измерение времени
Таймерный модуль имеет собственный регистр с разрядностью 2N.
Число, записанное в этот регистр, инкрементируется аппаратно на каждом
командном цикле ( если предделитель отключен). Регистр таймера может
инициализируется путем записи в него T0.
При переполнении этого регистра, т. е. при попытке записать в него число
равное 2N+1, модуль таймера вырабатывает сигнал прерывания, и ядро
микропроцессора осуществляет аппаратную передачу управления на обработчик
прерываний, который считает tic-и
tic [к] = 2N-T0
измерение в tic-ах системного таймера
Для пересчета в размерные единицы требуется конкретизации архитектуры
ядра ( длительность командного цикла в периодах тактовой частоты N и
используемой тактовой частоты f
tic [сек] = 1/(f * Nt)( 2N-T0)
Реализация измерения
A0
A1
A2
2
2
2
2
3
3
3
3
3
3
Прерывания от системного таймера
T
На время обработки прерываний от системного таймера производится приостановка
выполнения алгоритма, реализуемого компонентом, работа которого была прервана.
Для того, чтобы этот компонент мог после завершения обработки прерывания
корректно возобновить реализацию алгоритма в процессе обработки прерывания должны
быть, как минимум, сохранены значения ряда регистров ядра, так как при возврате из
прерывания значения этих регистров должны быть восстановлены.
ОСРВ как технология
С точки зрения технологии разработки программного обеспечения ОСРВ
является структурной основой разрабатываемого программного кода.
Эта структура определяется принятыми соглашениями и моделями базовых объектов.
Она формируется комплексом программно-инструментальных средств IDE
с использованием библиотек системных компонентов для работы с базовыми
объектами.
Существенным образом увеличивает коэффициент повторного использования
компонент , обеспечивает возможности распараллеливания работы в коллективе
разработчиков, облегчает организацию поддержки ПО
Стандарт POSIX
Семейство стандартов POSIX надо иметь ввиду при разработке системного
программного обеспечения Для ОСРВ наиболее важны семь спецификаций
POSIX (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h)
POSIX-совместимая ОС должна реализовать не менее 32 уровней приоритетов.
POSIX определяет три политики планирования обработки процессов:
 SCHED_FIFO
– процессы обрабатываются в режиме FIFO и выполняются до
завершения,
 SCHED_RR
– round robin – каждому процессу по очереди выделяется квант
времени,
 SCHED_OTHER – произвольная дисциплина диспетчеризации, не переносимая
на другие платформ
Стандарт 1003.1a (OS Definition) :
базовые интерфейсы ОС – поддержку единственногопроцесса, поддержку многих
процессов, управление заданиями, сигналами, группами пользователей, файловой
системой, файловыми атрибутами, управление файловыми устройствами, блокировками
файлов, устройствами ввода/вывода, устройствами специального назначения,
системными базами данных, каналами, очередями FIFO, а также поддержку языка C.
Стандарт 1003.1b (Realtime Extensions)
сигналы реального времени, планирование выполнения (с учетом приоритетов,
циклическое планирование), таймеры, синхронный и асинхронный ввод/вывод,
ввод/вывод с приоритетами, синхронизация файлов, блокировка памяти, разделяемая
память, передача сообщений, семафоры.
Стандарт 1003.1c (Threads)
функции поддержки многопоточной обработки внутри процесса, управление потоками,
планирование с учетом приоритетов, мьютексы (специальные синхронизирующие
объекты в межпроцессном взаимодействии, п одающие сигнал, когда они не захвачены
каким-либо потоком), приоритетное наследование в мьютексах, переменные состояния
(condition variables).
Стандарт ARINC
Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработан
компанией ARINC в 1997 г.
Этот стандарт определяет универсальный программный интерфейс APEX
(Application/Executive) между ОС авиационного компьютера и прикладным
программным обеспечением .
В 2003 г. принята новая редакция этого стандарта. ARINC-653.
Эта версия в качестве одного из основных требований для ОСРВ в авиации вводит
архитектуру изолированных (partitioning) виртуальных машин.
Каждое приложение (возможно, состоящее из нескольких процессов), должно
выполняться обособленно относительно других приложений и помещается в свой
собственный раздел.
Распространенные ОСРВ
 QNX

QN4

QNX6 (Neutrino)
 VxWorks
 OSEK/VDK

OSEK OS

OSEK Time triggered operating system
Очень сильно отличаются друг от друга организацией информационного
обмена между компонентами различных каналов и способами разделения
аппаратных ресурсов
Download