Требования к встроенным системам и системам реального времени

Главные идеи#

Чем отличаются такие проекты#

• Изменить оборудование после проектирования и производства стоит намного дороже, чем изменить ПО, поэтому архитектурные компромиссы решаются рано.
• Системные требования распределяются между программным обеспечением, оборудованием и людьми, и от этого число требований растёт, особенно требований к интерфейсам.
• Временные характеристики — самостоятельное требование.
• Среди атрибутов качества есть физические свойства.

Вигерс и Битти отличают системы жёсткого реального времени (hard real-time), где пропущенный срок ведёт к катастрофе (система управления воздушным движением не успела обнаружить препятствие), от систем мягкого реального времени (soft real-time), где это не так (банкомат просто повторяет попытку).

Требования и архитектура вместе#

Спецификация системных требований (SyRS, как она описана в стандарте ISO/IEC/IEEE) говорит, что должна делать система в целом, независимо от того, обеспечивает это ПО, оборудование или человек. Она может быть самостоятельным документом или включать спецификацию требований к ПО. Архитектуру (компоненты, их видимые свойства и связи между ними) разрабатывают итеративно, сверху вниз; обычно этим руководит системный инженер или архитектор с широкими техническими знаниями. Неудачное распределение приводит к тому, что ПО делает то, что оборудование сделало бы дешевле (или наоборот), люди делают то, что автоматика сделала бы дешевле, производительность страдает, а компоненты трудно модернизировать. Гибкость ПО не должна становиться поводом экономить на проектировании оборудования.

Полезные модели#

• Контекстная диаграмма: система и внешние сущности, с которыми она взаимодействует, — пользователи, датчики, другие системы.
• Диаграмма переходов состояний: состояния и события, которые переводят систему из одного состояния в другое.
• Таблица «событие — реакция»: требуемая реакция для каждого события в каждом текущем состоянии. Одно и то же событие в разных состояниях может требовать разной реакции.
• Архитектурная диаграмма: подсистемы и потоки данных и управления между ними. Если нарисовать её рано, она выявляет пропущенные функциональные требования и требования к интерфейсам.
• Периодические функции: работа, которая повторяется, пока система находится в некотором состоянии (например, опрос датчика раз в секунду), а не только при переходах.

Авторы рассказывают, как нарисовали диаграмму состояний по спецификации, которая существовала только в виде текстовой таблицы, и нашли два пропущенных требования: разные представления одних и тех же требований вскрывают разные дефекты.

Спецификации интерфейсов#

В сложных системах интерфейсы часто описывают в отдельном документе. Типичная структура: введение, диаграммы интерфейсов, интерфейсы данных (типы, форматы файлов, протоколы), программные интерфейсы (вызовы, синхронизация, протоколы), аппаратные интерфейсы (подключения, потоки данных и управления) и пользовательские интерфейсы. Анализ требований сосредоточен на внешних интерфейсах; внутренние относятся к проектированию.

Временные требования#

У времени три измерения: время выполнения (от начала до конца задачи), задержка (latency) (от события до реакции) и предсказуемость (насколько повторяемы временные характеристики — как у стабильной частоты дискретизации звука). Для каждой задачи выясните: - период и крайний срок, каждый — с допуском; - типичное и наихудшее время выполнения; - последствия пропуска срока; - минимальное, среднее и максимальное время поступления данных в каждом состоянии; - тайм-ауты и что происходит, когда они истекают; - требуемый порядок задач и какие задачи могут прерывать какие; - поведение, зависящее от состояния, — например, лифт в обычном режиме и в пожарном.

Ссылаясь на Купмана (Koopman), авторы подчёркивают: реальное время означает «достаточно быстро при наименьших общих затратах», а не «как можно быстрее». Излишне жёсткие временные требования поднимают стоимость оборудования.

Атрибуты качества, в том числе физические#

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