Код АЕЯР -значает изделие с приемкой "5", выпускаемое НИИЭТ и ВЗПП.
Код АЕЯР и набор цифр для ТУ на изделие с этой приёмкой. Это да. Но вообще говоря, с этим кодом хотя бы просто внутри этих предприятий могут быть совершенно разные изделия с совершенно разной приёмкой.
Я также считаю, что ПО должно следовать принципу KISS и работать однозначно. Но ПО бывает сделано почти, как ПО для Шаттла, где ЭВМ непрерывно пытается противодействовать каким-либо факторам и работать без вмешательства оператора. Такое ПО имеет очень большую сложность и обходится очень дорого по финансам и по времени. Но даже в этом ПО есть ошибки:
ссылка:
Но поразителен не объем работ, который выполняет программное обеспечение. Что действительно поражает, так это то, как хорошо это ПО работает. Это ПО никогда не падает. Оно никогда не требует перезагрузки. Оно не содержит ошибок. Оно совершенно, настолько совершенно, насколько человек смог этого достичь. Посмотрите на статистику: последние три версии этой программы – каждая по 420.000 строк кода – имели всего по одной ошибке в каждой. Последние 11 версии этого ПО имели в сумме 17 ошибок. Коммерческие программы, подобного уровня сложности имели бы 5.000 ошибок.
То есть, даже в этом случае ошибки неизбежны. Они были, есть и будут. И это в уникальном проекте. В рядовой программе те самые 5000 ошибок на 420 000 строк кода как минимум будут. Но проявляться они будут по-разному - некоторые и вовсе не проявятся за весь срок эксплуатации.
Проблема заключается в том, что ни один тест не может гарантировать безошибочность ПО. Он гарантирует только то, что программа прошла этот тест и всё.
Ошибки вида ""Например, проверяется совпадение некоторых условий - замечательно, но "любимая" ошибка новичков - не указать, какие действия выполнять, если ни одно из условий не выполняется" очевидны, гораздо опаснее ошибки, которые отражают тонкости работы программы и её частей между собой. И вот здесь, имея кучу флагов и переменных от различного оборудования очень легко что-то не предусмотреть. Такие ошибки проявляются по-разному. Скажем, должно придти прерывание по линии CAN от контроллера 82527 - оно в 99.999 случаев приходит. Но вот, вдруг, смотрим состояние CAN и видим, что данные в позиции CAN отмечены, а в прерывание программа не вошла. Как такое может быть? Прерывание никто не запрещал. Анализ ситуации сильно затруднён - поведение программы не очевидно (а она ещё и многопоточная, да ещё и со спецификой работы с потоками в QNX). Кто виноват, что нет прерывания? Что вообще происходит? Что же делать в этом случае? Никто не знает. Попытка решения путём рассуждений и анализа проблему не обнаруживают. Остаётся до понимания проблемы одно - непрерывно скидывать флаг занятости сообщения CAN в "свободно" (чтобы по данному арбитражу могли придти следующие данные) - это чревато возможной потерей пакета, но зато контроллер CAN не застрянет в состоянии, что ему некуда принимать данные.
Итак, мы практически в любом случае имеем программу с ошибками. Что делать, чтобы обеспечить её работоспособность в как можно большем количестве случаев? Перезагрузить программу. Поэтому не только микроконтроллеры, но и такие ОС реального времени, как QNX имеют в своём составе администратор высокой готовности - иными словами, сторожевой таймер с возможность перезапуска программы.
Из-за помех измеряется частота сети не 50 Гц, а в 2 раза выше - и программа, изволите ли видеть, "вылетает", блокирует котел! Кто её так написал?
Её так написал тот, кто не предполагал, что в сети будут столь сильные помехи. В конце-концов, всё же не следует решать программно все проблемы оборудования - это чрезмерно усложнит программу. Помехи в данном случае желательно устранять со стороны оборудования. А тот факт, что программой измерена "странная" частота сети и она зависает, конечно, удивителен - но, думается, эту программу писали не из соображений надёжности, а из соображений стоимость разработки/надёжность. Отсюда и столь странные результаты.
Измерительные же цепи автоматики могут тут быть и не при чём. Как-то нужно нам было по обычной экранированной двухпроводной линии соединить одну из линий нашего изделия с комплектом испытательной аппаратуры. Линия эта - обычные метки времени, частотой 1000 Гц и амплитудой 9 В, которые требовалось одновибратором немного растянуть. Всё бы ничего, но то, что работало в нашем стендовом зале и на спутнике, вдруг отказалось работать в чужом стендовом зале - уровень помех был чудовищным и сравнимым с уровнем сигнала - на такое мы в принципе не рассчитывали. Городить витую пару времени не было (у нас было 2 дня испытаний на всё), так что пришлось фильтровать на месте. Так и здесь, возможно, уровень помех по питанию оговорен в документации на котёл.
Собственно, больше сказать нечего. Ждём автора темы.
