Вградени Системи

Проектиране и Дизайн на РВС

 Мотивация
Някои класове приложения изискват строго контролиран процес
на проектиране и реализация:
Критични системи – автомобили, медицина, сигурност;
Комплексни системи – околна среда, екология, автоматизация;
Продукти, чувствителни към цена – масово производство
(домашна и персонална електроника);
Проекти, които се нуждаят от проследяемост на разработката,
документиране, и др.
Контролираният процес на проектиране и разработка, има за
цел:
Подобряване на качеството;
Въвеждане на стандарти и сертифициране;
Намаляване на времето за създаване;
Работа в силно диверсифицирани екипи (често отдалечени).
 Пример: резервоар с вода
Спецификация: контролер да следи нивото на водата в резервоара чрез
16-битов сензор и да го контролира чрез клапа (през реле).
Решение: разделяме софтуера на две основни функции – ReadLevel и
DoValve, които даваме на два екипа да реализират;
Първият екип използва 65535 стойности, кодиращи нивото (16-битов
сензор).
Втория проверява нивото на резервоара в метри, за да прецени дали
да отвори клапата.
Проблем: Получените функции са тествани по отделно и показват
работоспособност, спецификацията е изпълнена. За съжаление
крайната програма не изпълнява коректно задачата си, заради
разминаване на мерните единици.
Истински пример: Септември 1999, изкуствен спътник на Марс (Сървeйър)
изгаря в атмосферата на Марс, защото има разминавания в моделите на
екипите за навигация и конструкторите на спътника.
 Code & Fix

Методът на създаване на примерно приложение директно от

изискванията на клиента и последващото му
модифициране до постигане на крайния резултат се нарича
“постъпково прототипиране”
Недостатъци:
Няма документирани изисквания, подписани от двете страни;
Малки промени в изискванията могат да доведат до пълно
пренаписване на кода;
Невъзможност да се открият грешки в дизайна преди да се
пусне крайния продукт;
Непроследяемост на кода, невъзможност за лесно създаване на
нови версии, откриване на грешки и дупки в сигурността.
 V-model (1)

Решението на недостатъците на Code & Fix

Разделя създаването на 3 основни части – дизайн,
имплементация и тестване.
Разчита на дизайн “от общото към частното” и тестване в
обратния ред.
На всяка стъпка от дизайна се дефинират точните критерии
за бъдещо тестване.
Използва се за Системен дизайн, Софтуерно и Хардуерно
проектиране
Позволява рекурсивно включване на модели един в друг –
проектираната система включва хардуерен и софтуерна
част, които се разглеждат като нов модел от съответните
екипи.
V-model
 V-Model: Проектиране

• Анализ на спецификацията
(Requirements analysis)
• Системен дизайн (System Design)
• Архитектурен дизайн (Architecture
Design)
• Дизайн на модулите (Module Design)
 V-Model: Валидация

• Тестване на модулите (Unit Testing)

• Интеграционно тестване (Integration
Testing)
• Системнно тестване (System Testing)
• Тестване от потребителите (User
Acceptance Testing)
• Финално тестване (Release Testing)
 V-Model (2)

Жизнен цикъл на проектираната система

 Резервоар с вода (2)

• Дефиниране на спецификацията – има ли междинни нива, може

ли да се променя скоростта на пълнене
• Системен анализ и дизайн
• Определяне на софтуерните компоненти
• Дефиниране на хардуера
• Имплементация
• Тестване на хардуерните и софтуерни модули (Unit test)
• Интегриран тест на целия софтуер
• Тестване на софтуера върху таргет платформата.
• Верификация на готовия продукт
• Валидация на спецификацията
 Дизайн на вградени системи

Специфики:
• Електроника и хардуер;
• Автоматика и управляващи системи;
• Софтуерно обезпечаване и Операционни
системи;
• Комуникация и мрежови протоколи.
 Традиционен метод за проектиране

Това е реализация на Code&Fix с ранно разделяне на

софтуерното и хардуерно проектиране. На всяка стъпка се прави
прототип и се сравнява със спецификацията. Проблемът е, че
трудно се синхронизира работата на отделните екипи.
 Апаратно-Програмно ко-проектиране

Ко-проектирането позволява да се прави поведенчески и

функционален дизайн на хардуера и софтуера паралелно. Чрез
системно симулиране се откриват зависимости още по време на
проектирането, което позволява след създаване на архитектурен
модел да се раздели работата.
 Критични моменти в проектирането

Ко-проектирането позволява да се прави поведенчески и

функционален дизайн на хардуера и софтуера паралелно. Чрез
системно симулиране се откриват зависимости още по време на
проектирането, което позволява след създаване на архитектурен
модел да се раздели работата.
 Embedded V-Model

При вградените системи V модела може да покаже

кои дейности се извършват на Хост системата и
кои на Таргет системата.
 V-Model (2)

Общ вид на модела

Роли в жизнения цикъл на продукт

Съгласно основния стандарт в индустрията за

автомобилна електроника и софтуер.