Требования к математическому обеспечению - пункт ТЗ на АС, разрабатываемого согласно ГОСТ 34.602. Как элемент иерархической структуры техзадания может быть представлен так: Требования к системе (разд. 4) ⇨ ...к видам обеспечения (подр. 4.3) ⇨ ...к математическому обеспечению (п. 4.3.1). Чем же заполнять данный пункт? Редакция от 06.01.2022.

Создан 29.04.2018 17:05:49

Пункт (4.3.1) Требования к математическому обеспечению во многом «перекрывается» подпунктом 4.1.13.3 Типовые математические методы и модели, поэтому добавить особо нечего, разве что старчески побрюзжать на тему подобных «перекрытий», а их, как можно заметить, в техническом задании по ГОСТ 34.602 встречается множество.

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

Но что же мы имеем:

1. Требования к системе (разд. 4) ⇨ ...в целом (подр. 4.1) ⇨ ...по стандартизации и унификации (п. 4.1.13) ⇨ Типовые математические методы и модели (пп. 4.1.13.3).
2. Требования к системе (разд. 4) ⇨ ...к функциям (задачам), выполняемым системой (подр. 4.3) ⇨ ...к математическому обеспечению (п. 4.3.1).

Каким боком математические методы и модели, пусть даже типовые, оказались в требованиях по стандартизации и унификации? Разве не достаточно в п. 4.1.13 указать, что требования по стандартизации и унификации распространяются на все виды обеспечения АС, а типовые математические методы и модели (с их полным перечнем) сбросить сюда, в п. 4.3.1, поскольку им самое место в требованиях к математическому обеспечению?

При таком раскладе все сразу встает на свои места: взаимная ортогональность обеспечивается, любая взаимозависимость исключается, содержимое релевантно своим заголовкам. А пока либо 4.3.1 оказывается пустым (в нем просто нечего больше писать), либо 4.1.13.3 избыточным и нерелевантным. Либо наоборот.

Взаимная ортогональность

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

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

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

Минимизация взаимозависимости

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

Многие, наверное, догадываются о том, что у самолета или вертолета два или несколько двигателей не только потому, что мощности одного недостаточно, но и потому, что при отказе одного из двигателей оставшиеся выступают в качестве практически всех перечисленных выше типов резерва. Дорого, а что делать? Зато снижается риск возникновения предпосылок к летным происшествиям (авиационным инцидентам), объект (летательный аппарат) оказывается «общезарезервированным».

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

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

Релевантность

Релевантность обеспечивает, как минимум, значительное упрощение поиска чего-либо, ведь всегда гораздо быстрее и проще найти то, что лежит исключительно на своем, строго определенном месте, когда все разложено по полочкам.

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

Детально реализация принципа релевантности рассмотрена здесь.