Отдельно стоит остановиться в этом пункте на вопросе составления бюджетов на уровне требований и составления бюджетов на уровне проекта. Проект на уровне системы – на самом деле логическая интеграция проектов сегментов. Определяя, "как хорошо" выполнить функцию и какие интерфейсы поддержать, мы создаем структуру для принятия решения "как" проектировать каждый сегмент. Для миссии FireSat "как хорошо" касается точности местоположения и распределения по сегментам эфемерид, ориентации и других точностей. "Как" касается решения космического сегмента относительно того, добавить ли звездный датчик или гироскоп для достижения требуемой точности ориентации. Если бы только в жизни было так просто. В действиях миссии должна быть намечена калибровка звездного датчика и юстировка гироскопа, так чтобы космический аппарат смог выполнить требования. Поэтому мы должны документировать и процедуры, и интерфейсы данных. Кроме того, действия миссии требуют понимания системы управления ориентацией спутника, чтобы уберечь ее от неправильного использования при планировании действий. И в планировании калибровки или юстировки, действия миссии требуют понимания датчиковой полезной нагрузки и другой электронной аппаратуры, которые могут быть выведены из строя неосторожными маневрами относительно Солнца. Системные и сегментные спецификации обеспечивают требования, а спецификации низшего уровня обеспечивают проектирование, но интерфейсы нарушают это ясное разделение труда. Фактически, системный инженер и проектировщики сегментов должны взаимодействовать на уровне проектов.
Начальные бюджетные оценки почти никогда полностью не соответствуют реальным особенностям проекта на более низких уровнях. Ясно, что ранние бюджеты - исходные точки для честного обсуждения и бюджетного урегулирования, чтобы выверить раннее распределение системы с оценками характеристик сегмента. Когда требования выверены, они должны быть зафиксированы в сводке требований, которая может изменяться только при полном согласии проектировщиков сегмента, инженеров системы и программных менеджеров. Каждый из этих критических параметров характеристик соответствует установленному системному и сегментному бюджету. Эти бюджеты могут и обычно изменяются, когда разработчики переходят к проектированию и утверждают истинные характеристики.
В этой стадии составления бюджета понятие проектного запаса становится проблемой. В частности, сколько разумно держать, кто знает, где он, и кто имеет полномочия, чтобы уступить часть из него? Сначала, если каждый уровень разработки содержит большой запас, система будет стоить гораздо больше, чем необходимо. Обычно запас является статистическим (например, требования ошибки в 2s), и когда он проходит через несколько стадий, он может производить существенную избыточность конструкции и стоимости. Часто инженеры проекта прикрывают себя, храня этот запас на более низких уровнях проекта, где он имеет тенденцию быть невидимым или годным для перераспределения. Здесь предписание не может занимать место здравого смысла. Иногда запас может обеспечивать ошибкоустойчивость против орбитальных отказов, но это может также вызвать проблемы. Например, слишком большой запас в звеньях связи мог бы фактически подавлять приемники. Ключевые требования системы должны иметь запас, но мы должны отслеживать его на уровне систем, чтобы мы могли уступать или выбирать его по мере необходимости для минимизации риска.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.