Выводы из управления требованиями: сбои при преобразовании единиц измерения

При разработке аппаратных продуктов инженеры каждый день обмениваются числовыми значениями. Значение переходит от инженера в чертеж, из спецификации в компонент или от вашей команды к поставщику. В большинстве случаев это работает, потому что все понимают, что означает число и в каких единицах оно указано.

Риск возникает, когда это значение проходит через точку передачи, а две стороны интерпретируют его по-разному. Одна сторона может работать в фунтах, тогда как другая ожидает килограммы. В одном документе может использоваться старая имперская система, а новый проект уже выполнен в метрической. Число может выглядеть правильным для обеих сторон, но оно уже не определяет одно и то же инженерное решение.

Три приведенные ниже инженерные истории показывают, насколько легко это может произойти:

Три случая, один шаблон

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

Рейс 143 Air Canada: планер Гимли

Первый пример — это планер Гимли 1983 года. Он показывает, что произошло, когда авиакомпания Air Canada перешла с имперских единиц на метрические. Рейс 143, Boeing 767, следовавший из Монреаля в Эдмонтон, был первым самолетом авиакомпании, работавшим в метрической системе.

В тот день система индикации количества топлива (FQIS) не работала, поэтому экипаж измерял топливо вручную. Они использовали значение плотности 1,77 от заправщика — в фунтах на литр, что было стандартом для остальной части флота. Но для метрического 767 это значение требовалось в килограммах на литр, где правильное число составляло около 0,8.

Самолет взлетел, имея только половину топлива от того количества, на которое рассчитывал экипаж, из-за чего в полете остановились оба двигателя. К счастью, пилотам удалось благополучно посадить самолет.

Mars Climate Orbiter

Шестнадцать лет спустя Mars Climate Orbiter был потерян из-за навигационной ошибки, вызванной тем, что английские единицы не были переведены в метрические. Программное обеспечение Lockheed Martin передавало данные о тяге в фунт-сила-секундах. Навигационное ПО NASA ожидало ньютон-секунды, которые отличаются от фунт-сила-секунд в 4,45 раза.

Космический аппарат должен был выйти на орбиту на высоте от 150 до 200 километров над Марсом. Вместо этого он снизился примерно до 57 километров и сгорел в атмосфере Марса.

Американские горки Space Mountain в Tokyo Disneyland

В 2003 году американские горки Space Mountain в Tokyo Disneyland показали похожую проблему, проявившуюся через конструкторские чертежи. В 1995 году аттракцион был перечерчен из имперской системы в метрическую, при этом диаметр оси изменился с 44,14 до 45 миллиметров. Однако старые чертежи не были выведены из обращения, и в результате существовало два комплекта конструкторской документации.

В 2002 году, когда был повторно заказан новый комплект осей, заказ основывался на версии конструкции до 1995 года. В результате детали оказались заниженного размера. Эта разница в 0,86 миллиметра сделала зазор в подшипнике значительно больше, чем предполагалось. После нескольких месяцев эксплуатации ось сломалась.

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

Эта иллюстрация напоминает: значение может выглядеть правильным для всех и при этом оставаться ошибочным — согласны ли обе стороны в вашей точке передачи относительно единицы измерения?

Чему аппаратные команды могут научиться из этих историй

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

Указывайте единицы измерения для каждого значения в требованиях

Само по себе число недостаточно. «45» не говорит следующему участнику процесса, что именно нужно изготовить или проверить. «45 мм» придает числу смысл. Каждый раз сохраняйте единицу измерения рядом со значением. Это не деталь форматирования; это часть требования.

Назначайте ответственного за каждую инженерную передачу

Путаница с единицами часто возникает, когда информация переходит от одной команды к другой. Одна сторона может работать по одному исходному документу, а другая ожидать другой. У такой передачи должен быть четко назначенный владелец. Кто-то должен проверить систему единиц, формат данных и исходный документ, прежде чем значение будет использовано на следующих этапах.

Поддерживайте трассируемость требований и подтверждающих данных

Когда значение изменяется, команде нужно быстро находить все, что от него зависит. Это означает, что требование, чертеж, компонент, тест и подтверждающие данные не должны существовать как разрозненные элементы. Трассируемость помогает команде видеть, откуда пришло значение, где оно используется и что нужно пересмотреть при его изменении.

Как помогает связанный процесс работы с требованиями

Более эффективный процесс управления требованиями сохраняет число, его единицу измерения, владельца и исходный документ рядом друг с другом. Он не рассматривает значение как просто отдельное число в таблице, чертеже или спецификации.

Особенно важно это в точках передачи. Когда значение переходит из требования в проектную работу или верификацию, следующий участник может увидеть, что означает это значение, в каких единицах оно задано и откуда оно взялось. Если значение изменится, команда также сможет определить, что именно требует пересмотра.

Altium Requirements Portal поддерживает такой процесс, сохраняя требования, ответственность, трассируемость и работу по верификации в одной общей среде. Он не заменяет инженерную оценку. Он помогает сохранять видимость единицы измерения, владельца и связанного инженерного контекста до того, как значение будет использовано на следующих этапах.

Ключевые выводы

• Путаница с единицами часто начинается в точках передачи, когда значение переходит в другую команду, документ или систему, а его единица измерения не указана достаточно явно.
• Прежде чем число станет основой для следующего инженерного шага, команда должна понимать, откуда оно пришло и кто за него отвечает.
• Трассируемость помогает командам видеть, что зависит от значения, прежде чем оно изменится или будет передано дальше по процессу.

Каждое ли число в вашем проекте является полным?

Каждый из этих инцидентов можно было предотвратить. Не за счет «лучшей инженерии», а за счет четких вопросов, заданных в точке передачи:

• Есть ли у каждого значения в ваших требованиях указание единицы измерения?
• Есть ли у каждого интерфейса между командами назначенный ответственный?
• Понятно ли, какая версия спецификации является текущей?
• Если завтра что-то изменится, покажет ли ваш процесс, что нужно пересмотреть?

Теперь задайте те же вопросы применительно к своему проекту. Если ответ на любой из них — «скорее всего», вы уже знаете, с чего начать.

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

Начать работу с Requirements Portal →

Часто задаваемые вопросы

Почему в инженерных проектах возникают ошибки преобразования единиц?

Такая путаница редко связана с плохими вычислениями. Она возникает в точках передачи, когда значение перемещается между командами, инструментами или документами. Одна сторона может предполагать, что значение задано в одних единицах, тогда как другая интерпретирует его в других. Само значение при этом может быть правильным, но правильным для неверного предположения.

Что должно включать полное значение требования?

Полное значение требования должно включать число, единицу измерения и контекст, необходимый для его корректного использования. Например, «45» недостаточно; «45 миллиметров» — достаточно. Команде также может потребоваться знать условие, при котором применяется это значение, исходный документ и того, кто владеет этим требованием.

Как трассируемость помогает снизить количество ошибок при передаче?

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