Пример отсутствия дублирования при взаимодействии модулей/coupling

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

В главе поднимается вопрос, где проводить проверку между модулями:

  • выходной контроль
  • входной контроль
  • и так и сяк
  • никак

В таких системах, как космическая техника. Особенно, когда речь идёт об уникальных научных миссиях обычно не экономят и проверяют и на выходе и на входе. Но иногда случается так, как было в 2003 году с американским спутником NOAA-19.

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

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

Т.е. даже при присутствии дублирования дизайн-тайм организации, в ран-тайм что-то пошло не так, что привело к убыткам на 135 млн. долларов.

2 лайка

Очень хорошо =) К вопросу о том, что каким бы хорошим не был конкретный инженер, архитектор и т.д. самое слабое звено может порушить всю систему.

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

Я сразу пытаюсь думать: а что могло помочь не произойти этой ситуации? Кажется, что и пункты чек-листов прекрасно игнорируются или ставится галочка с мыслью “да попозже документирую, пара минут не решают”… Ну вы поняли, что будет дальше

1 лайк

Если по-житейски ответить, то помог бы прораб, который не имеет отношения ни к одному из оргзвеньев.

Не знаю кто он в ролях. Супервизор какой-нибудь.

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

2 лайка

Дело в том, что и техника с компьютерным зрением будет завязана на человеческий фактор и т.д. В моей любимой информационной безопасности есть похожая проблема - шифрования данных. Надежное шифрование подразумевает наличие хорошего ключа, который защищенно хранится за пределами базы. Для пущей безопасности сам ключ шифруют другим ключом, который прячут ещё дальше. Но чтобы мы не делали возможны ситуации а-ля “фильмы братьев Коэн” - когда одаренные люди умудряются сложить оба ключа в одну базу, и защита превращается в тыкву. Уверен, и самое совершенное компьютерное зрение будет “посрамлено” человеческой “смекалкой”, при чем провал может прийти и со стадии кривого проектирования, и со стадии кривой разработки, и со стадии кривого внедрения, и со стадии кривой эксплуатации. Т.е. да, безусловно, надо копать в эту сторону, но нет - это не гарантирует нам защиту именно от таких ситуаций, что описаны в статье.

1 лайк

А про гарантии никто и не писал.

1 лайк

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

Хотя это тоже не 100% гарантии.

Еще один вариант это консилиум со все возможными парными проверками на входе.

Ну чек-листы видимо хромые были и без проговаривания.