Слайды

1. All you need is conf.uml2.ru6
Работа с требованиями при
создании программного
обеспечения бортовой
радиоэлектронной аппаратуры
Лалетин Сергей

2. ЛАФ 6, 2015 г.
Лалетин Сергей
ГосНИИАС
2001 – 2007
Rockwell Collins
2007 – н.в.
sglaletin@gmail.com

3. ЛАФ 6, 2015 г.
Цель доклада
Показать основные моменты, которые
касаются работы с требованиями, при
создании программного обеспечения
бортовой радиоэлектронной аппаратуры с
учетом использования стандарта RTCA DO-
178C (Software Considerations in Airborne
Systems and Equipment Certification)
3

4. ЛАФ 6, 2015 г.
План доклада
Документ DO-178C
Виды и типы требований
Уровни критичности ПО
Выявление требований
Проверка требований
Документы
Связные документы с RTCA DO-178C
Применение UC (UML и SysML)
Что бывает, если ....
Использованные источники
Заключение
4

5. ЛАФ 6, 2015 г.
Введение
Функциональность современного бортового радиоэлектронного
оборудования определяется встраиваемым программным
обеспечением.
Общий процент человеческих трудозатрат, связанный с созданием и
проверкой бортового ПО, составляет 60 процентов и более, в
зависимости от типа оборудования и его критичности.
Любая функциональная особенность должна быть определена
требованиями. Требования разрабатывают люди. Людям свойственны
ошибки. Фактически, на сегодняшний день, нет общего языка для
разработки требований в текстовом виде, как и нет средств
автоматизированной или автоматической проверки требований на их
корректность и полноту.
Иногда, к разработанным требованиям можно применить высказывание
Г. Гегеля: Великий человек обрекает людей на то, что бы они его
объясняли.
5

6. ЛАФ 6, 2015 г.
Стандарт с иллюстрацией
6
CONSENSUS n. Collective opinion or concord; general agreement or accord.
[Latin, from consentire, to agree]
Illustration provided by Pat Neilan, UK CAA

7. ЛАФ 6, 2015 г.
Документ DO-178C
System Life Cycle Processes
Hardware Life Cycle Processes
Software Life Cycle Processes
7

8. ЛАФ 6, 2015 г.
Процессы (DO-178C)
1. Процессы планирования ПО
2. Процессы разработки ПО
3. Процессы управления конфигурациями ПО
4. Процессы обеспечения качества
5. Процессы проверки ПО
6. Процессы сертификации ПО
8

9. ЛАФ 6, 2015 г.
Процессы разработки (DO-178C)
1. Процессы определения требований к ПО
2. Процессы определения архитектуры и
дизайна ПО
3. Процессы кодирования ПО
4. Процессы интеграции ПО
9

10. ЛАФ 6, 2015 г. 10
Поток информации
Техническая спецификация
заказчика - PTS
Документы системного уровня
Документы уровня ПО
Отраслевые стандарты
Стандарты заказчика
HLR LLR Derived Req.

11. ЛАФ 6, 2015 г.
Уровни критичности ПО
Level A – Catastrophic. Отказ может привести к
катастрофической отказной ситуации
Level B – Hazardous. Отказ может привести к
непредсказуемой отказной ситуации
Level C – Major. Отказ может привести к
существенной отказной ситуации
Level D – Minor. Отказ может привести к
несущественной отказной ситуации.
Level E - No Safety Effect. Отказная ситуация
отсутствует
11

12. ЛАФ 6, 2015 г.
Уровни критичности ПО
Уровень критичности ПО определяется в
результате процесса оценки безопасности
системы.
Должны быть проанализированы следующие
факторы:
• Потеря функциональности или
неправильная функциональность
• Воздействие внешних факторов
12

13. ЛАФ 6, 2015 г.
Жизненный цикл разработки (V-
Model)
13

14. ЛАФ 6, 2015 г. 14
Жизненный цикл разработки (V-
Model)
Phase 1 Phase 2 Phase 3 Phase … Phase N Phase N+1

15. ЛАФ 6, 2015 г.
Этапы проекта
…………………..
SRR - System Requirements Review
SDR - System Design Review
PDR - Preliminary Design Review
CDR - Critical Design Review
PRR - Production Readiness Review
…………………..
15

16. ЛАФ 6, 2015 г.
Эволюция продукта (разработка)
16
Prototype Blue Label Red label
Black Label Certification Product

17. ЛАФ 6, 2015 г.
Определение требования
Требование к ПО (Software requirement) –
описание того, что должно быть выполнено
программным обеспечением, учитывая
входные данные и ограничения.
Требование к ПО может быть как
требованием высокого уровня(LLR), так и
требованием низкого уровня(HLR).
17

18. ЛАФ 6, 2015 г.
Системные требования
Системные требованя к программному
обеспечению, включают в себя:
• Функциональные и эксплуатационные
требования
• Требования к интерфейсам
• Требования к производительности
• Требования к безопасности (Safety) и
защищенности (Security)
• Требования к обслуживанию
18

19. ЛАФ 6, 2015 г.
Требования высокого уровня
Требования высокого уровня (High-level
requirements) – требования к программному
обеспечению, разработанные на основе
анализа системных требований, требований к
безопасности и системной архитектуре
19

20. ЛАФ 6, 2015 г.
Требования низкого уровня
Требования низкого уровня (Low-level
requirements) – требования к программному
обеспечению, разработанные на основе
требований высокого уровня, новых
требований, появившихся в процессе
разработки (derived requirements) и
ограничений. Исходный код разрабатывается
на основе требований низкого уровня (LLR).
20

21. ЛАФ 6, 2015 г.
Derived requirements
Новые требования, появившиеся в процессе
разработки (Derived requirements) –
требования, появившиеся в процессе
разработки программного обеспечения,
которые прямо не ссылаются на требования
высокого уровня, но уточняют
функциональность, определенную
системными требованиями или
требованиями высокого уровня.
21

22. ЛАФ 6, 2015 г.
Характеристики требования
Требование должно быть:
• тестируемым
• реализуемым
• ясным для понимания
• законченным
• полным
22

23. ЛАФ 6, 2015 г.
Анализ покрытия: Требования vs
тестовые процедуры vs код
Dead code – Выполняемый код, непокрытый
требованиями
Extraneous code – Выполняемый код,
непокрытый требованиями, для примера, код
унаследованный от другой системы
Deactivated code – Выполняемый код,
покрытый требованиями, но не
используемый, или не предназначенный для
использования (robustness programming)
23

24. ЛАФ 6, 2015 г.
Техники выявления и уточнения
требований
Анализ документов и стандартов (отрасль,
закачик)
Проведение регулярных внутренних и
внешних совещаний
Официальная переписка с заказчиком
и т.д.
24

25. ЛАФ 6, 2015 г.
Разработка требований и общий
подход
Для разработки требования используется
глагол “shall”, для рекомендации
используется глагол “should”, “must”, “will”.
Примеры требования:
The I/O interface shall be ARINC 429.
The power-up event shall be logged each time.
25

26. ЛАФ 6, 2015 г.
Проверка требований высокого
уровня
1. Проверка на соответствие требованиям
системного уровня
2. Проверка на точность и полноту
3. Проверка на программно-аппаратную
совместимость
4. Проверка на тестируемость
5. Проверка на соответствие стандартам
6. Проверка на прослеживаемость (Traceability)
7. Проверка на правильность предложенных
алгоритмов
26

27. ЛАФ 6, 2015 г.
Проверка требований низкого
уровня
1. Проверка на соответствие требованиям высокого
уровня
2. Проверка на точность и полноту
3. Проверка на программно-аппаратную
совместимость
4. Проверка на тестируемость
5. Проверка на соответствие стандартам
6. Проверка на прослеживаемость (Traceability)
7. Проверка на правильность предложенных
алгоритмов
27

28. ЛАФ 6, 2015 г.
Документация
The Plan for Software Aspects of Certification
The Software Development Plan
The Software Verification Plan
The Software Configuration Management Plan
The Software Quality Assurance Plan
The Software Requirements Standards
The Software Design Standards
The Software Code Standards
The Software Verification results
28

29. ЛАФ 6, 2015 г.
Связные документы дополнения
• RTCA DO-331 "Model-Based Development
and Verification Supplement to DO-178C and
DO-278"
• RTCA DO-332 "Object-Oriented Technology
and Related Techniques Supplement to DO-
178C and DO-278A"
• RTCA DO-333 "Formal Methods Supplement
to DO-178C and DO-278A"
• RTCA DO-330 "Software Tool Qualification
Considerations"
29

30. ЛАФ 6, 2015 г.
Что бывает если
Тип ВС: Boeing 777
Год происшествия: 2005
Авиакомпания: Malaysia Air
Маршрут: Perth, Australia - Kuala Lumpur, Malaysia
Авиационное происшествие: Воздушное судно совершило
самопроизвольный маневр
Причина: Отказ в INS
Детали: Дефект ПО INS позволил INS принять недостоверные
данные от отказавшего акселерометра
Последствия: FAA выпустила экстренную директиву для
поддержания летной годности всего парка самолетов типа
Boeing 777 и обязала всех эксплуатантов выполнить
обновление ПО, с целью устранения дефекта
30

31. ЛАФ 6, 2015 г.
UML и SysML
• SysML применяется на уровне System Life
Cycle Processes
• UML применяется на уровне Software Life
Cycle Processes
• Модели не являются требованиями.
Требованиями является только текст,
содержащий “shall”
31

32. ЛАФ 6, 2015 г. 32
Requirements Diagram in SysML

33. ЛАФ 6, 2015 г.
Заключение
• Модели из Model Based Requirements
Engineering применяются только как
дополнительные разъясняющие материалы к
требованиям в текстовом виде
• Модели из Model Based Development
(Simulink, SCADE) применяются для
разработки систем с высоким уровнем
критичности, с последующим
самогенерирующемся кодом
33

34. ЛАФ 6, 2015 г.
Заключение
Для эффективной работы с требованиями,
необходимо:
• Знание предметной области
• Знание и умение применять отраслевые
стандарты
• Иметь аналитические способности/навыки
• Знание применяемых инструментов
• Уметь работать в комманде
34

35. ЛАФ 6, 2015 г. 35
Заключение
RTCA DO в России переводятся и адаптируются в
виде КТ МАК.
RTCA DO-178B (1992) -> КТ-178В (2004)
RTCA DO-178C (2011) -> КТ-178С (?)
RTCA DO-254 (2000) -> КТ-254 (2011)
Отставание в среднем на 10 лет и более

36. ЛАФ 6, 2015 г.
Использованные источники
1. RTCA DO-178C Software Considerations in
Airborne Systems and Equipment Certification
www.rtca.org
2. Avionics Magazine
www.aviationtoday.com/av/
36

37. Вопросы?

38. 6-й Летний
Аналитический
Фестиваль
г. Иваново
20-21 июня 2015
conf.uml2.ru
All you need is …