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

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

2. Встроенные системы управления СТРУКТУРА –ФУНКЦИИ-COCTAB

3. выходы входы Ns к-во датчиков Na к-во каналов управления ОБЪЕКТ КОНТРОЛЛЕР ИЛИ СЕТЬ КОНТРОЛЛЕРОВ MMI человеко-машинный интерфейс входы: кнопки, клавиатуры, сетевые интерфейсы…… выходы: дисплеи, светодиоды, аудио …… ОБОБЩЕННАЯ СТРУКТУРА СИСТЕМЫ УПРАВЛЕНИЯ Воздействия среды • Система управления – это устройство или набор устройств, предназначенных • для обеспечения требуемого поведения объекта или объектов управления • В общем случае требуется система управления класса MIMO • ( Multiple Inputs –Multiple Outputs)

4. Состав системы управления Система управления включает в себя аппаратную и программные компоненты. Наличие аппаратного обеспечения, адекватного по структуре и составу функциям системы управления, является необходимым условием для возможности создания системы управления. Однако даже идеально спроектированная с аппаратной точки зрения система не работоспособна без соответствующего программного обеспечения. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ - ЭТО СЛОЖНЫЙ ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС, ТРЕБУЮЩИЙ СООТВЕТСТВУЮЩЕЙ ОРГАНИЗАЦИИ, ИНСТРУМЕНТАРИЯ И КВАЛИФИЦИРОВАННОГО ПЕРСОНАЛА

5. Функции системы управления • НОРМАЛЬНЫЕ РЕЖИМЫ ЭКСПЛУАТАЦИИ • Система управления реального времени встраиваемого класса должна • обеспечивать выработку управляющих воздействий на основании задаваемого • режима управления и обработки показаний датчиков о состоянии системы. • Принципиально важным является необходимость обеспечения сбора • данных и выработки управляющих воздействий по многим каналам со • специфицированными временными параметрами, обеспечивающими • актуальность данных и воздействий. • РЕЖИМЫ С НАРУШЕНИЯМИ НОРМАЛЬНЫХ УСЛОВИЙ ЭКСПЛУАТАЦИИ • АВАРИЙНЫЕ РЕЖИМЫ

6. Встроенные системы управления ТЕХНОЛОГИЧЕСКИЕ ЦИКЛЫ РАЗРАБОТКИ СИСТЕМ УПРАВЛЕНИЯ

7. Характеристики техпроцесса Среднее количество строк исходного кода в приложении выросло с 8000 в начале 90x до 1000000 к 2005 г. И продолжает расти с темпом, определяемым законом Мура. При этом в настоящее время операции тестирования занимают от 50 до 70 процентов от общей трудоемкости по разработке программного обеспечения. Сам процесс разработки приобретает черты сложного технологического процесса, выполняемого большими коллективами разработчиков. Как следствие, это приводит к специализации функций и регламентации базовых этапов и операций.

8. Стандарты разработки ПО Формализация применяемых процедур тестирования и привязка их к международным стандартам является одним из ключевых условий возможности организации международной кооперации в аэрокосмической сфере. Естественным следствием этого является появление отечественного аналога американского авиационного стандарта DO-178B в виде ГОСТ Р 51904, введенного в действие в 2002 году. Стандарт европейской организации по стандартизации космической техники ECSS-E-40C представляет собой очередную попытку формализации процесса разработки программного обеспечения. Этот стандарт идейно совместим со стандартами DO-178B и ГОСТ Р 51904.

9. Код команды Адреса операндов Параметры ГОСТ Р 51904 Алгоритм Конечное множество четко определенных правил, которые задают последовательность действий при выполнении конкретной задачи. КомпонентПредставляет собой замкнутую часть, комбинацию или элемент, который выполняет в системе отдельную функцию. Компонент представляет собой набор команд, оформленный в соответствии с правилами, определяемыми используемым программным инструментарием. Программный код. Способ реализация конкретных данных или конкретной компьютерной программы в символьной форме, например, как исходный код, объектный код или машинный код • В англоязычной литературе и документации этому понятию соответствует “code” или “program code”,которые обозначают программу, представленную в виде набора команд. • Команда представляет собой битовую строку, состоящую из нескольких полей, а программный код набор линейно упорядоченных команд PC ++ ПАМЯТЬ ПРОГРАММ

10. Трансляция или компиляция кода, сборка кода Описание алгоритма на ассемблере, макроассемблере, языке С, JAVA Прошивка кода в макет устройства или в опытный образец Корректировка описания алгоритма модификация алгоритма Отладка с использованием симулятора Отладка с использованием внутрисхемного эмулятора Стандартный цикл разработки программного обеспеченияавтономного узла Отладка. Это ключевой элемент цикла разработки систем управления встраиваемого класса, заключающийся в проверке возможности обеспечения специфицированных параметров на макете или опытном образце системы при использовании текущей версии программного обеспечения.

11. Предпроектные исследования, спецификация требований и разработка технического задания Тестирование системы на приемо-сдаточных испытаниях Разработка архитектуры системы Интеграция и комплексное тестирование системы Интеграция и тестирование программного обеспечения Проект системы Тестирование модулей Проекты модулей Кодирование V-модель разработки ПО • Стандарт МЭК 61508 ”Функциональная безопасность систем электрических, электронных, • программируемых электронных, связанных с безопасностью”

12. Оценка параметров, ограничений и альтернатив Оценка технологических и финансовых рисков Изготовление аппаратной и программных компонент Разработка аппаратной и программной компонент Разработка концепции и спецификаций Макетиро-вание рисков Опытный образец Серийный образец Макет Стоимость know-how Системная интеграция Разработка и согласование ТЗ на опытный образец Тестиро-вание Автономное тестирование Опытная эксплуатация Комплексное тестирование Планирование следующей итерации Оценка реализуемости требований Спиралеобразная модель разработки полного цикла

13. КЛАССИФИКАЦИЯ СПОСОБОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

14. ГЕНЕРАТОРЫ ПРИЛОЖЕНИЙ Базовые элементы: настраиваемое приложение Описание алгоритма предполагает использование специализированного программного инструментария обслуживающего параметризованное описание алгоритма в составе готового изделия • ТЕХНОЛОГИИ ОСРВ и mОСРВ • Базовые элементы: нить, процесс, поток • Описание алгоритма предполагает использование специализированной структуры программного обеспечения, специализированных библиотек и специализированной IDE Маршрут разработки Up-DOWN Маршрут разработки Down-Up • КОМПОНЕНТНОЕ (процедурное) ПРОГРАММИРОВАНИЕ • Базовый элементы: компонент (функция) и библиотеки функций • Алгоритм описывается с использованием ассемблера, языка С, JAVA • Для создания программного кода используются инструментальные • программы обслуживания библиотек и сборки программного кода ЛИНЕЙНЫЙ ПОДХОД . Базовый элемент – задача. Алгоритм описывается с использованием ассемблера, макроассемблера и/или языков С., JAVA Иерархия методов разработки ПО

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

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

17. Механизм реализации • На ассемблере MPASM фирмы Microchip структура подпрограммы имеет вид: • PROC //Cимвольное имя_подпрограммы • [Тело подпрограммы: последовательность команд на ассемблере] • return // • Работа с подпрограммой осуществляется посредством двух команд вызова подпрограммы CALL ивозврата RETURN и использует стэк • CALL PROC PC<-адрес SUB RETURN PC PC+1 PROC PROC1 ПАМЯТЬ ПРОГРАММ

18. Преимущества • Компонентное программирование, рассматриваемая как технология, существенно • повышает эффективность работы коллектива программистов в смысле • интегральной скорости разработки, качества создаваемого программного • обеспеченияи стоимости. • Интегральная скорость разработки повышается за счет распараллеливания • процесса разработки, а качество за счет возможности использования • уже проверенных на практике компонент. • Стоимость сокращается за счет уменьшения трудоемкости конечного продукта • Требуется, как минимум, дополнительный инструментарий : • редактор связей ( linker) • библиотекарь (librarian • и более сложная технология разработки, которая подразумевает документирование процесса, синхронизацию версий, аппаратно-программную совместимость средств разработки.

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

20. СИСТЕМНЫЙ ТЕРМИНАЛ Пользовательский Терминал 1 ВНЕШНИЕ НАКОПИТЕЛЬ_1 ПРОЦЕССОР ВНЕШНИЕ НАКОПИТЕЛЬ _K Пользовательский Терминал_2 Пользовательский Терминал_K ВВОД ПЕЧАТЬ Операционная система Берет свое начало от вычислительных центров коллективного пользования и представляет собой специализированное программное обеспечение • Базовые функции : • обеспечение интерфейсов с внешними устройствами • предоставление ресурсов пользовательской программе • обработка сбойных ситуаций

21. ВЫХОДНЫЕ ПОТОКИ ВХОДНОЙ ПОТОК ЗАЯВОК НА ОБСЛУЖИВАНИЕ Обслуженные заявки ОЧЕРЕДЬ Станция обслуживания Не обслуженные заявки Математический аппарат Модели систем массового обслуживания (СМО) впервые были разработаны для телефонных станций Время поступления заявок, их время обслуживание заявки являются случайными, соответственноэтому, анализ систем проводится вероятностными методами Аналитические решения ряда ключевых параметров таких систем были получены для одноканальных систем с отказами и систем с ожиданием для канонических форм входного потока: потоки Эрланга, Пуассона и .т.п.

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

23. Управление аппаратной составляющей ВНЕШНИЕ УСТРОЙСТВА Задача пользователя Диспетчер OC Процессор Память Задача пользователя MMI Задача пользователя ФУНКЦИИ ОС Программное обеспечение = операционная система + прикладное ПО ОС обеспечивает для прикладных компонентов необходимые ресурсы вычислительной системы и контролирует процесс его выполнения Ключевые элементы ОС: диспетчер и диспетчер прерываний Системные компоненты Прикладной компонент_1 Прикладной компонент_K ПАМЯТЬ ПРОГРАММ

24. A 1 1 1 1 A0 1 A1 2 A2 2 3 A3 4 T T=0 Tf Tс • системный компонент; 2 – измерительный компонент по NS каналам; • 3-вычислительный компонент; 4 – компонент выработки команд управления по NA каналам; Многоуровневое описание алгоритмов Процессограмма модельной системы управления

25. 1-й поток 2-й поток 3-й поток Временной слот Ti Цикл K Цикл K+1 Цикл K+2 Время Цикл опроса Tc очереди задач T Системный вызов диспетчера Tsys = Tisr+Tdisp Поток микроядра Пример процессограммы для RR диспетчера Диспетчеризация Диспетчер(sheduler). Представляет собой системный компонент, обеспечивающийпорядок обработки информации в многоканальных системах управления, путем запуска соответствующих прикладных компонент кода. Запуск компонента на выполнение подразумевает выделение ему требуемых ресурсов ( память, процессор и периферия) Базовые дисциплины диспетчеризации FIFO, RR, RR c приоритетами

26. Диспетчер прерываний Одной из важнейших функций диспетчера является обеспечения ресурсами компонент, обрабатывающими сигналы прерываний. При этом требуется обеспечить корректную приостановку процесса реализации текущей задачи с тем, чтобы после обработки сигнала прерывания, его можно было возобновить без возникновения ошибок. При этом не следует забывать о необходимости выполнять временные ограничения по времени выполнения прерванного компонента. СК К1i К2i Кmi СК К1 К2 Кm ПАМЯТЬ ПРОГРАММ

27. 1-й поток 2-й поток 3-й поток Временной слот Ti Цикл K Цикл K+1 Цикл K+2 Время Цикл опроса Tcочереди Системный вызов диспетчера Tsys = Tisr+Tdisp Поток микроядра Пример процессограммы для RR диспетчера Базовые дисциплины диспетчеризации При переключении с компонента на компонент системные компоненты обеспечивают сохранение и восстановление регистров ( ядра по крайней мере)

28. ОСРВ

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

30. выходы входы Ns к-во датчиков Na к-во каналов управления ОБЪЕКТ КОНТРОЛЛЕР ИЛИ СЕТЬ КОНТРОЛЛЕРОВ MMI человеко-машинный интерфейс входы: кнопки, клавиатуры, сетевые интерфейсы…… выходы: дисплеи, светодиоды, аудио …… ОБОБЩЕННАЯ СТРУКТУРА СИСТЕМЫ УПРАВЛЕНИЯ Воздействия среды • Система управления – это устройство или набор устройств, предназначенных • для обеспечения требуемого поведения объекта или объектов управления • В общем случае требуется система управления класса MIMO • ( Multiple Inputs –Multiple Outputs)

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

32. Понятие реального времени. • В соответствии с пунктом 3.2.1 стандарта IEE 610.12:1990 понятие реальное время • (real-time) относится к системе или режиму функционирования, для которого • вычисления выполняются за характерное время внешнего процесса, для того • чтобы результат вычислений мог быть использован для управления, мониторинга • или ответа во временном темпе, определяемым внешним процессом. • Это определение используется и в современной системе европейских • стандартов для аэрокосмических применений. • Часто используют определение: • системы управления реального времени – это такие системы, у которых время реакции на внешнее воздействие не превышает специфицированного по каждомуиз каналов управления/воздействия, обозначаемое как tdeadline.

33. WCET-ACET На практике используются еще два способа. Спецификации худшего времени выполнения tWCET(WCET - Worst CaseExecution Time) Спецификации среднего времени выполнения tACET(ACET -Average Case Execution Time ) tACET < tWCET < tdeadline Осталось сделать еще один шаг и признать, что время реакции является вероятностной величиной

34. Измерение времени Таймерный модуль имеет собственный регистр с разрядностью 2N. Число, записанное в этот регистр, инкрементируется аппаратно на каждом командном цикле ( если предделитель отключен). Регистр таймера может инициализируетсяпутем записи в него T0. При переполнении этого регистра, т. е. при попытке записать в него число равное 2N+1, модуль таймера вырабатывает сигнал прерывания, и ядро микропроцессора осуществляет аппаратную передачу управления на обработчик прерываний, который считает tic-и tic [к] = 2N-T0 измерение в tic-ах системного таймера Для пересчета в размерные единицы требуется конкретизации архитектуры ядра ( длительность командного цикла в периодах тактовой частоты N и используемой тактовой частоты f tic [сек] = 1/(f * Nt)( 2N-T0)

35. A0 A1 2 2 2 2 A2 3 3 3 3 3 3 Прерывания от системного таймера T Реализация измерения На время обработки прерываний от системного таймера производится приостановка выполнения алгоритма, реализуемого компонентом, работа которого была прервана. Для того, чтобы этот компонент мог после завершения обработки прерывания корректно возобновить реализацию алгоритма в процессе обработки прерывания должны быть, как минимум, сохранены значения ряда регистров ядра, так как при возврате из прерывания значения этих регистров должны быть восстановлены.

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

37. Стандарт 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– произвольная дисциплина диспетчеризации, не переносимая • на другие платформ

38. Стандарт 1003.1a (OS Definition) : базовые интерфейсы ОС – поддержку единственногопроцесса, поддержку многих процессов, управление заданиями, сигналами, группами пользователей, файловой системой, файловыми атрибутами, управление файловыми устройствами, блокировками файлов, устройствами ввода/вывода, устройствами специального назначения, системными базами данных, каналами, очередями FIFO, а также поддержку языка C. Стандарт 1003.1b (Realtime Extensions) сигналы реального времени, планирование выполнения (с учетом приоритетов, циклическое планирование), таймеры, синхронный и асинхронный ввод/вывод, ввод/вывод с приоритетами, синхронизация файлов, блокировка памяти, разделяемая память, передача сообщений, семафоры. Стандарт 1003.1c (Threads) функции поддержки многопоточной обработки внутри процесса, управление потоками, планирование с учетом приоритетов, мьютексы (специальные синхронизирующие объекты в межпроцессном взаимодействии, подающие сигнал, когда они не захвачены каким-либо потоком), приоритетное наследование в мьютексах, переменные состояния (condition variables).

39. Стандарт ARINC Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработан компанией ARINC в 1997 г. Этот стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным программным обеспечением . В 2003 г. принята новая редакция этого стандарта. ARINC-653. Эта версия в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин. Каждое приложение (возможно, состоящее из нескольких процессов), должно выполняться обособленно относительно других приложений и помещается в свой собственный раздел.

40. Распространенные ОСРВ • QNX • QN4 • QNX6 (Neutrino) • VxWorks • OSEK/VDK • OSEK OS • OSEK Time triggered operating system Очень сильно отличаются друг от друга организацией информационного обмена между компонентами различных каналов и способами разделения аппаратных ресурсов