Средства и методы разработки

Каждый раз когда говорится о "выбросах", "помехах" и "оптронах" начинаю понимать, что говорящие не понимают как оно работает. Почему полупроводниковый прибор должен быть хуже реле, и почему там должны быть какие-то "выбросы". Не говоря уж о том, что есть специальные приборы, тоже полупроводниковые, предназначенные для борьбы с "выбросами". Реле в первую очередь имеет деградацию при работе. В отличии от обычного транзистора, если последний не загоняют в какие-то исключительные режимы. Например обычное реле в схеме включения поворотников в машине долго не выдержит. Кроме того, реле не может так запросто размыкать силовую (индуктивную) нагрузку и требует какого-либо механизма защиты контактов, не может работать с очень низкими (менее 1мА) токами, требует отвода тепла (и сопротивление обмотки у него возрастёт, при перегреве, настолько что оно не сможет работать _раньше_, чем откажет PIC24 -- проверено на практике). Наконец в условиях вибрации реле работают тоже не очень. С чего взяли что реле -- это какой-то волшебный прибор мне непонятно. Ту же схему можно сделать на транзисторах и она может оказаться куда более надёжной. Про дефекты: программист делает ошибку на каждые несколько (50 например) строчек кода. Я имею ввиду ошибку, которая компилируется. В процессе тестирования и отладки их остаётся (по данным "НАСА") примерно одна на тысячу строк. На мой взгляд очень даже похоже на действительности при программировании на языках C/C++. И надо понимать, что значительная часть оставшихся ошибок не простейшие опечатки, не то, что могут увидеть разные анализаторы кода, это -- логические ошибки. Когда программист осознанно делает не то, что следовало бы, а что-то другое. Проблема в том, что этапа проектирования "логических функций" программы не было, логику выдумывал программист из головы в процессе написания кода. И эта логика часто весьма неполноценна. Альтернативой могло бы быть введение отдельных этапов проектирования ПО, на котором производятся следующие действия: 1) система управления, её программная часть, разбивается по компонентам, для каждого компонента определяется какие функции он выполняет, создаётся диаграмма связей компонентов; 2) на основе диаграммы связей компонентов создаётся диаграмма взаимодействия (message passing diagram), которая описывает последовательности вызовов функций или передачи сообщений между компонентами -- на данном этапе, разумеется, предусмотреть все варианты невозможно и такие диаграммы создаются для ряда явно выделенных сценариев, определяющихся функциональностью системы управления; 3) строится система конечных автоматов, взаимодействующая по правилам из предыдущего пункта. В процессе её проработки, возможно, придётся рекурсивно возвращаться на предыдущие этапы; 4) при этом, в частности, явно выделяются множество событий, сообщений, вызовов функций -- всё что может является событием для изменения состояния какого-либо автомата, явно выделяются множества возможных состояний автоматов, и явно выделяются все возможные управляющие выходные воздействия (что потребуется в пункте 6); 5) система конечных автоматов проходит базовые проверки на корректность: что все состояния достижимы, что нет "зависаний" в состояниях без выхода, что есть осмысленная реакция на любое возможное входное событие в каждом состоянии; 6) вводится набор правил, заданных в рамках временной логики, для проверки правильности работы системы в целом: например, что после нажатия такой кнопки должно быть произведено такое-то действие, что после такого-то события не допустимо другого действия (при повышении температуры выше 40 градусов нагреватель не должен включаться, иначе эмбрионы помрут); 7) система автоматов может быть закодирована на специальном языке (SPIN) в специальной среде (Promela) и проверена на корректность по правилам заданным в предыдущем пункте; 8) система конечных автоматов кодируется на обычном языке программирования, отлаживается, тестируется; 9) набор правил из пункта 6 отдельно кодируется как, условно, параллельная программа обнаруживающая сбой в управляющей программе (особенно если пункт 7 не выполнялся), так же проектируется и программируется упрощённый алгоритм управления для обработки аварийных ситуаций... 10) если по итогам тестирования нужно внесение изменений в логику работы, то оно не делается программистом непосредственно -- оно должно пройти согласование на всех пунктах, начиная с самого первого -- это принципиальный момент. Обычно кое-как выполняется пункт 1, редко пункт 2, сразу переходят к пункту 8, причём без возврата назад при любых переделках. Других пунктов обычно нет. Когда даже понятия о конечных автоматах и состоянии системы управления, или программы в целом, как совокупности состояния всех задач и их переменных нет (почему программирование с явным выделением состояния лучше...), конечный автомат превращается в недетерминированный -- разные его "задачи" находятся не пойми в каком состоянии, часто в новых состояниях, не предусмотренных программистом и получившихся случайно, что является бесконечным источником разнообразных сбоев, ошибок и прочих неожиданностей. Сам факт хранения состояния не в единой переменной состояния, а использование массы разных переменных и флагов запросто и на пустом месте умножает число состояний до астрономических величин.