Насколько различаются резервные компьютеры управления полетом?

Что касается Airbus:

1. Каждый блок состоит из двух разных плат, одна из которых управляет выходом, а другая проверяет его. Непохожие означают как разные процессоры, так и наборы микросхем (A320 использует i386 (Intel) и m68k (Motorola); в более новых моделях используются другие комбинации, в основном те, которые широко использовались в то время, когда они были разработаны), а также программное обеспечение, написанное двумя независимыми командами.

2. Есть аварийные переключения, два или три в зависимости от системы (IIRC, устройство, считывающее боковые джойстики, является единственным с четырьмя копиями).

3. Две основные оси, тангаж и крен, контролируются двумя разными системами. ELAC управляет рулем высоты и элеронами, SEC управляет горизонтальным стабилизатором и спойлерами. Это две полностью независимые цепочки, включающие в себя разные собственно рули, за исключением боковых стиков.

4. A320 имеет (гидро) механическую резервную копию для тангажа с помощью триммера и рыскания с помощью педалей, используя муфту рыскания и крена для крена. Это работает даже при полном отказе электропроводки. IIRC резервных копий на более новых моделях нет (потому что полного отказа электросети никогда не было).

Избыточность достигается не только за счет увеличения количества компьютеров, но и за счет их разнообразия. На авиалайнерах Airbus используются два разных компьютера (один с чипами Intel, другой с чипами Motorola в случае A320), и программное обеспечение пишется дважды, одно для управления, другое для мониторинга, двумя командами, которым не разрешено взаимодействовать. .

Цитата из главы 12 Справочника по авионике :

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

2 ELAC (компьютеры руля высоты и элеронов) и 3 SEC (компьютеры спойлеров и руля высоты) на A320/A321 и,

3 FCPC (первичные компьютеры управления полетом) и 2 FCSC (дополнительные компьютеры управления полетом) на A330/A340.

Возьмем, к примеру, модель 320. ELAC производятся компанией Thomson-CSF на основе микропроцессоров 68010, а SEC производятся в сотрудничестве с SFENA/Aerospatiale с аппаратным обеспечением на основе микропроцессора 80186. Таким образом, у нас есть две разные проектные и производственные группы с разными микропроцессорами (и связанными с ними схемами), разными компьютерными архитектурами и разными функциональными характеристиками. На уровне программного обеспечения архитектура системы приводит к использованию четырех программных пакетов (канал управления ELAC, канал мониторинга ELAC, канал управления SEC и канал мониторинга SEC), когда функционально достаточно одного.

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

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

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

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

У Fast Company был отличный отчет о процессе написания программного обеспечения для космического челнока. Хотя он не имеет прямого отношения ни к Airbus, ни к Boeing, он дает представление о том, как работал процесс и к чему он привел.

Первичные системы должны иметь идентичные компьютеры и программное обеспечение, как это имеет место на многих компьютерах бортовых систем транспортных средств. Однако независимые системы резервного копирования должны иметь разные системы и программное обеспечение в зависимости от архитектуры, требований и схем управления резервированием для обеспечения безопасности. Помимо средств управления полетом, которые действительно имеют различия в аппаратном обеспечении, основные полетные дисплеи для сторон пилота и второго пилота для воздушной скорости и инерциальной навигации часто имеют тройное резервирование, чтобы сохранить функцию пространственного положения. Они правильно используют идентичные 3 компьютера навигационной системы, тогда как «резервный» отличается с точки зрения критических функций безопасности полета и детерминизма. Общая системная архитектура, состоящая из параллельных или более (триплексных) систем, должна иметь независимые и резервные системы, отвечающие установленным агентством и нормативным требованиям критериям безопасности и летной годности, а также надежности и доступности. Как правило, наличие идентичных компьютеров для «основных систем» потребует тщательного тестирования с внесением ошибок в сочетании со сложным взаимодействием, что сведет к минимуму возможность ошибок программного обеспечения, а иногда и необоснованные опасения, что дефекты каким-то образом проявятся в задержке. Надлежащее тестирование во всех средах является ключом к получению избавиться от любых дефектов, которые могут вызвать потенциальную опасность и риск.Рекомендуются методы безопасности программного обеспечения для предотвращения, устранения и контроля таких проблем, чтобы обеспечить соблюдение требований безопасности и летной годности.В этих случаях требуется анализ безопасности и независимые проверки с утверждениями.