Несмотря на все тяжкие процессы сертификации, качество верификации ПО часто оставляет желать лучшего. И к бизнес-джетам это относится наверное даже в большей мере, чем к остальным бортам.
Возможно, что:
— этот участок кода вообще не проверялся автоматическими тестами
— проверялся, но недостаточно хорошо (пара стандартных наборов данных), поэтому факт комментирования кода не был отловлен
— были fail'ы в тестах, но проблему прохлопали/посчитали несущественной и она прошла сертификацию
— этот «умный код» иногда глючил, и решили на текущей сертификации его убрать (отразив это в требованиях). Но, как видите, что-то забыли.
Разновидность последнего вариант разгребал лично несколько лет назад как раз на бизнес-джете. Правда тогда это был испытательный полет и кривой код к заказчикам не попал (но там и «эффект» гораздо круче был :))
Датчики обжатия стоек шасси тоже резервируюся.
Например на каждой стойке их стоит 6 штук, и сигнал WOW считается сработавшим если среагировало как минимум 4 датчика.
У нас на работе был доклад по предварительным данным расследования, и какое было мнение на тот момент:
Из-за бокового ветра не было одновременного обжатия стоек шасси (приземлилась только одна сторона), из-за чего не включались автоматически интерсепторы и блокировалось включение реверса.
Подобные неприятности (без катастроф) встречались и с другими судами, где потом чуть меняли логику: если обжалась правая стойка шасси, то выпустить автоматически интерсепторы с левой стороны, и соответсвенно наоборот.
Но фактически причина — ошибка экипажа, который взял скорость захода на посадку сильно больше рассчетной (экипаж долго летал на на ТУ-154, у которого эта скорость еще существенно выше — привычка сработала).
Применяется иногда.
Например в одном из самолетов стоит 5 дисплеев, два из кторорых разрабатываются по уровню A, остальные по уровню B (как менее критические).
Железо там тоже разное.
Но требования… хоть документы и разные, они пересекаются почти 100% и все обновления ПО делаются параллельно в обоих ветках, причем зачастую одновременно и одними и теми же людьми.
Т.е. если будет придуман некий глючный алгоритм, то с вероятностью 99% он попадет в обе ветки ПО.
Причина такого разделения именно в том самолете мне не ясна.
Или хотели как лучше, а получилось — как всегда. Или пытались сэкономить на железе уровня A. Или от того, что дисплеев 5 (а не 4), не хватило каналов Arinc чтоб все их подключить с доблированием линий.
Эх, работая в разработке бортового ПО уже много лет могу сказать, что тенденции не самые хорошие.
Причем идут и послабления со стороны стандартов (которые пишут в США), и массовая передача самого процесса разработки в Индию и Китай.
Последние хоть и живут в современном мире, голова у них всё еще в деревне.
Как результат, качество ПО сильно падает. Причем они даже пытаются проектные стандарты править так, что они перестают соответсовать «библии» DO-178.
Топливо, ГСМ, преиодическое обслуживание узлов (каждые XX часов полета).
А также, каждая посадка стоит денег. Например, если самолет рассчитан на X посадок (рассчетная величина и на шасси, и на планер), то каждая посадка стоит <стоимость самолета>/X.
Вот поэтому ПО должно сертифицироваться гораздо жестче, чем железо. Ведь в основе резервиорования заложено функционирование в случае апаратного отказа в одном из блоков. А если случается лажа по причине багов в ПО (например деление на 0), то при переключении на резервный блок такая же лажа случится и в нем с очень большой вероятностью.
Спасибо за замечания.
В данный момент тулза проходит бета-тестирование. Уже нашел и исправил пару косяков.
Как только всё устаканится, обновлю скрипты в статье и, по возможности, поправлю терминологию.
Возможно, что:
— этот участок кода вообще не проверялся автоматическими тестами
— проверялся, но недостаточно хорошо (пара стандартных наборов данных), поэтому факт комментирования кода не был отловлен
— были fail'ы в тестах, но проблему прохлопали/посчитали несущественной и она прошла сертификацию
— этот «умный код» иногда глючил, и решили на текущей сертификации его убрать (отразив это в требованиях). Но, как видите, что-то забыли.
Разновидность последнего вариант разгребал лично несколько лет назад как раз на бизнес-джете. Правда тогда это был испытательный полет и кривой код к заказчикам не попал (но там и «эффект» гораздо круче был :))
Но и более привычные RS-422 и Ethernet (возможно чуть модифицированный) тоже встречаются.
Например на каждой стойке их стоит 6 штук, и сигнал WOW считается сработавшим если среагировало как минимум 4 датчика.
Из-за бокового ветра не было одновременного обжатия стоек шасси (приземлилась только одна сторона), из-за чего не включались автоматически интерсепторы и блокировалось включение реверса.
Подобные неприятности (без катастроф) встречались и с другими судами, где потом чуть меняли логику: если обжалась правая стойка шасси, то выпустить автоматически интерсепторы с левой стороны, и соответсвенно наоборот.
Но фактически причина — ошибка экипажа, который взял скорость захода на посадку сильно больше рассчетной (экипаж долго летал на на ТУ-154, у которого эта скорость еще существенно выше — привычка сработала).
Например в одном из самолетов стоит 5 дисплеев, два из кторорых разрабатываются по уровню A, остальные по уровню B (как менее критические).
Железо там тоже разное.
Но требования… хоть документы и разные, они пересекаются почти 100% и все обновления ПО делаются параллельно в обоих ветках, причем зачастую одновременно и одними и теми же людьми.
Т.е. если будет придуман некий глючный алгоритм, то с вероятностью 99% он попадет в обе ветки ПО.
Причина такого разделения именно в том самолете мне не ясна.
Или хотели как лучше, а получилось — как всегда. Или пытались сэкономить на железе уровня A. Или от того, что дисплеев 5 (а не 4), не хватило каналов Arinc чтоб все их подключить с доблированием линий.
В пассажирской главное — жизнь людей.
В военной допускается снижение безопасности экипажа ради повышения боевой эффективности.
Причем идут и послабления со стороны стандартов (которые пишут в США), и массовая передача самого процесса разработки в Индию и Китай.
Последние хоть и живут в современном мире, голова у них всё еще в деревне.
Как результат, качество ПО сильно падает. Причем они даже пытаются проектные стандарты править так, что они перестают соответсовать «библии» DO-178.
А также, каждая посадка стоит денег. Например, если самолет рассчитан на X посадок (рассчетная величина и на шасси, и на планер), то каждая посадка стоит <стоимость самолета>/X.
Я думаю, что экипаж там — самое дешевое.
В данный момент тулза проходит бета-тестирование. Уже нашел и исправил пару косяков.
Как только всё устаканится, обновлю скрипты в статье и, по возможности, поправлю терминологию.