slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ PowerPoint Presentation
Download Presentation
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Loading in 2 Seconds...

play fullscreen
1 / 40

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


  • 364 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

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


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

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

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

Лекция 8

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

slide2

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

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

slide3

выходы

входы

Ns

к-во датчиков

Na

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

ОБЪЕКТ

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

MMI

человеко-машинный

интерфейс

входы:

кнопки, клавиатуры,

сетевые интерфейсы……

выходы:

дисплеи, светодиоды,

аудио ……

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

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

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

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

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

компоненты.

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

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

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

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

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

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

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

slide5

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

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

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

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

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

slide7

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

Среднее количество строк исходного кода в приложении выросло с 8000 в

начале 90x до 1000000 к 2005 г. И продолжает расти с темпом,

определяемым законом Мура.

При этом в настоящее время операции тестирования занимают от 50 до 70 процентов от общей трудоемкости по разработке программного обеспечения.

Сам процесс разработки приобретает черты сложного

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

разработчиков.

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

базовых этапов и операций.

slide8

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

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

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

Стандарт европейской организации по стандартизации космической техники

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

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

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

slide9

Код команды

Адреса операндов

Параметры

ГОСТ Р 51904

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

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

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

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

инструментарием.

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

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

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

PC ++

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

slide10

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

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

сборка кода

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

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

языке С, JAVA

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

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

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

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

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

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

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

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

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

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

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

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

slide11

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

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

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

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

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

Разработка

архитектуры

системы

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

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

системы

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

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

Проект

системы

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

модулей

Проекты

модулей

Кодирование

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

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

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

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

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

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

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

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

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

Разработка

концепции и

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

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

рисков

Опытный

образец

Серийный

образец

Макет

Стоимость

know-how

Системная

интеграция

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

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

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

Опытная

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

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

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

итерации

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

требований

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

slide13

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

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

slide14

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

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

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

  • ТЕХНОЛОГИИ ОСРВ и mОСРВ
  • Базовые элементы: нить, процесс, поток
  • Описание алгоритма предполагает использование специализированной структуры программного обеспечения, специализированных библиотек и специализированной IDE

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

Up-DOWN

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

Down-Up

  • КОМПОНЕНТНОЕ (процедурное) ПРОГРАММИРОВАНИЕ
  • Базовый элементы: компонент (функция) и библиотеки функций
    • Алгоритм описывается с использованием ассемблера, языка С, JAVA
    • Для создания программного кода используются инструментальные
    • программы обслуживания библиотек и сборки программного кода

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

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

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

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

slide15

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

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

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

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

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

slide16

Компонентное программирование

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

Высокого уровня

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

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

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

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

PC<-адрес SUB

RETURN

PC

PC+1

PROC

PROC1

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

slide18

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

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

СИСТЕМНЫЙ

ТЕРМИНАЛ

Пользовательский

Терминал 1

ВНЕШНИЕ

НАКОПИТЕЛЬ_1

ПРОЦЕССОР

ВНЕШНИЕ

НАКОПИТЕЛЬ _K

Пользовательский

Терминал_2

Пользовательский

Терминал_K

ВВОД

ПЕЧАТЬ

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

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

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

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

ВХОДНОЙ ПОТОК

ЗАЯВОК НА ОБСЛУЖИВАНИЕ

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

ОЧЕРЕДЬ

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

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

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

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

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

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

Аналитические решения ряда ключевых параметров таких систем были получены

для одноканальных систем с отказами и систем с ожиданием для канонических

форм входного потока: потоки Эрланга, Пуассона и .т.п.

slide22

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

Появление вычислительных машин существенно расширило возможность

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

структурой станции обслуживания

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

имитационного моделирования систем ( пакеты семейства GPSS)

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

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

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

Как правило, интерес представляет вероятность отказа в обслуживании,

среднее время нахождения заявки в очереди, вероятности отсутствия заявок

на каком-либо элементе станции обслуживания

slide23

Управление

аппаратной

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

ВНЕШНИЕ

УСТРОЙСТВА

Задача

пользователя

Диспетчер

OC

Процессор

Память

Задача

пользователя

MMI

Задача

пользователя

ФУНКЦИИ ОС

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

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

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

Ключевые элементы ОС: диспетчер и диспетчер прерываний

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

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

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

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

slide24

A

1

1

1

1

A0

1

A1

2

A2

2

3

A3

4

T

T=0

Tf

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

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

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

slide25

1-й поток

2-й поток

3-й поток

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

Цикл K

Цикл K+1

Цикл K+2

Время

Цикл опроса Tc очереди задач T

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

Tsys = Tisr+Tdisp

Поток

микроядра

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

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

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

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

slide26

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

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

компонент, обрабатывающими сигналы прерываний.

При этом требуется обеспечить корректную приостановку процесса реализации

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

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

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

выполнять временные ограничения по времени выполнения прерванного компонента.

СК

К1i

К2i

Кmi

СК

К1

К2

Кm

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

slide27

1-й поток

2-й поток

3-й поток

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

Цикл K

Цикл K+1

Цикл K+2

Время

Цикл опроса Tcочереди

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

Tsys = Tisr+Tdisp

Поток

микроядра

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

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

При переключении с компонента на компонент системные компоненты

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

slide29

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

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

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

внешних возмущающих воздействий

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

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

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

slide30

выходы

входы

Ns

к-во датчиков

Na

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

ОБЪЕКТ

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

MMI

человеко-машинный

интерфейс

входы:

кнопки, клавиатуры,

сетевые интерфейсы……

выходы:

дисплеи, светодиоды,

аудио ……

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

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

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

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

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

WCET-ACET

На практике используются еще два способа.

Спецификации худшего времени выполнения

tWCET(WCET - Worst CaseExecution Time)

Спецификации среднего времени выполнения

tACET(ACET -Average Case Execution Time )

tACET < tWCET < tdeadline

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

slide34

Измерение времени

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

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

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

инициализируетсяпутем записи в него T0.

При переполнении этого регистра, т. е. при попытке записать в него число

равное 2N+1, модуль таймера вырабатывает сигнал прерывания, и ядро

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

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

tic [к] = 2N-T0

измерение в tic-ах системного таймера

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

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

slide35

A0

A1

2

2

2

2

A2

3

3

3

3

3

3

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

T

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

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

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

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

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

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

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

slide36

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

С точки зрения технологии разработки программного обеспечения ОСРВ

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

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

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

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

объектами.

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

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

разработчиков, облегчает организацию поддержки ПО

slide37

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

Стандарт 1003.1a (OS Definition) :

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

Стандарт 1003.1b (Realtime Extensions)

сигналы реального времени, планирование выполнения (с учетом приоритетов,

циклическое планирование), таймеры, синхронный и асинхронный ввод/вывод,

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

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

Стандарт 1003.1c (Threads)

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

slide39

Стандарт ARINC

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

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

Этот стандарт определяет универсальный программный интерфейс APEX

(Application/Executive) между ОС авиационного компьютера и прикладным

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

В 2003 г. принята новая редакция этого стандарта. ARINC-653.

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

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

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

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

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

slide40

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

  • QNX
  • QN4
  • QNX6 (Neutrino)
  • VxWorks
  • OSEK/VDK
  • OSEK OS
  • OSEK Time triggered operating system

Очень сильно отличаются друг от друга организацией информационного

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

аппаратных ресурсов