Требования к временному сегменту 1:
Требования к временному сегменту 2:
Время от обнаружения до доставки данных |
Начальное распределение |
|
Первоначальное подтверждение (PD/PFA, количество захватов, время на обработку данного обнаружения) |
1 мин |
|
Сброс данных на Землю (наличие линии, захват/закрытие линии) |
3 мин |
|
Определение орбиты и ориентации |
6 мин |
|
Определение точки наблюдения на Земле |
2 мин |
|
Завершение наземной обработки (архитектура обработки, количество каналов, скорость обработки) |
3 мин |
|
Подтверждение пожара (отношение автоматизированных и ручных операций, количество операторов, и рабочих станций) |
3 мин |
|
Подготовка данных (сортировка, форматирование, внутренняя маршрутизация) |
2 мин |
|
Организация очереди для распределения к пользователю (сортировка, распределение, обработка) |
3 мин |
|
Распределение к конечному потребителю (сетевое управление, канальные скорости) |
2 мин |
|
Запас |
5 мин |
|
30 мин |
Рис. 4-4. Бюджет времен и требований данных миссии.
Фактическое время от обнаружения пожара до распределения срочных данных связано и с охватом, и с определенными временными требованиями
Системные инженеры должны понимать, как размещать и обсуждать бюджеты, устанавливать требования, и пошагово испытывать системную целостность. Неудача при выполнении этих ключевых бюджетов может привести к большим системным проблемам. Если мы начинаем действовать достаточно рано, то имеется время перераспределять, отдавать обратно некоторые запасы или изменять эксплуатационные процедуры, и это будет быстрее, чем ожидать фактической интеграции на уровне систем или приемочных испытаний, чтобы обнаружить проблемы.
Составление бюджета характеристик и подтверждение ключевых требований системы - итеративный процесс, как показано на рис. 4-5. Однако прежде чем процесс может фактически начаться, определенный параметр характеристики и соответствующая формулировка требования должны быть ясны и трассируемы к потребности миссии. Это легко говорить, но тяжелее делать, даже после нескольких итераций. Хотя мы можем желать диктовать требования быстро, неопределенные или непоследовательные требования или неточное понимание может привести к неверным истолкованию и/или эксплуатации. Эти неудачи особенно применимы к критическим областям характеристик системы, и без полного взаимодействия и ранней проверки опытного образца они могут стать дорогими и угрожающими программе позже.
Рис. 4-5. Итеративное составление бюджета характеристик и проверка правильности.
Начальный бюджет характеристик - отправная точка для более поздней оценки проекта сегмента и испытания на проверку правильности. Проект будет сходиться к утвержденной величине, которая может потребовать, чтобы урегулирование бюджета на системном уровне соответствовало изменениям
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.