2 из 3 голосования с использованием метода указателей функций для проектирования государственных машин

Question

Я работаю над системой безопасности, которая требует от меня проведения голосования 2oo3. Я грубо имею идею реализации этого с использованием государственных машин с помощью указателей функций. Предположим, что существует 3 системы, AB C. Относительно A, C - система слева, а B - правая система. . Что касается B, A - левая система, а C - правая система В отношении C, B - левая система и C - правильная система

Для каждого решения, которое принимает система, оно должно заставить указатель функции указывать на функцию «обмен данными с левой системой». После того, как данные отправлены в левую систему, он указывает на фиктивную функцию и ждет ответа левой системы.

Когда левая система отвечает и ее решение (левая система) также согласуется с решением, принятым системой (моей системой), оно переходит в следующее состояние. Если он не согласен, он должен повторить то же самое с «обмениваться данными с правильной системой» и продолжить.

Мое сомнение здесь в том, что я не хочу реализовывать с использованием флагов для управления переходом состояния, является реализация с использованием указателей функций, так что нигде MISRA 2004 не говорит о том, чтобы использовать указатели функций?

Является ли подход к реализации 2oo3, как указано выше, или есть что-то еще, о чем нужно позаботиться?

Есть ли какие-либо другие подходы к внедрению архитектуры 2oo3 (нет внешнего компаратора для принятия решений каждой системой, то есть каждый uC должен сам принять решение и проконсультироваться с его решением с другим 2.It не будет принимать решение во внешнем компараторе (например: разделяемая память, компаратор на основе fpga и т. д.) для доступа и сравнения другими системами 2)?

Пожалуйста, простите меня, если я подошел к нему неправильно. Я новичок в этом.

(Примечание: 3 системы имеют только микроконтроллеры)

UPDATE: Некоторые полезные пункты были добавлены @Lundin здесь - State Machine design with no function pointers

Answer 1

Мои сомнения здесь, так как я не хочу, чтобы реализовать с помощью Флаги для управления переходом состояния - это реализация с использованием указателей функций, поэтому нигде MISRA 2004 не говорит о том, чтобы использовать указатели функций?

Откуда у вас эта идея? В любом стандарте MISRA-C нет ничего запрещающего использования указателей функций. MISRA-C едва упоминает указатели на функции. Единственное, что MISRA-C не допускает, - это дикие броски между указателями функций и регулярными указателями, поскольку это вызывает неопределенное поведение.

Фактически стандартный способ реализации государственных машин обычно имеет переменную состояния, такую ​​как перечисление, которое указывает на индекс в массиве указателей на функции. Here - типичный пример, который с кратким взглядом кажется 100% совместимым с MISRA.

Является ли подход к реализации 2oo3, как указано выше, или есть что-то еще, о чем нужно позаботиться?

Никто не может говорить, не зная ваших требований.Обычно при разработке таких критически важных для безопасности систем (большинство избирателей) вы хотите, чтобы фактическое «голосование» было размещено на аппаратных средствах вне процессоров, хотя цель его заключается в защите от сбоев в работе подсистем/процессоров. (Аппаратный «избиратель» сам по себе может быть под контролем, в свою очередь). Таким образом, есть некоторые проблемы с вашим подходом:

• Главный вопрос: если А опросы B, но сам пошел наперекосяк, это будет потом " ложь "о голосовании от Б. По существу коррумпированный узел А затем получит 2 голоса, и вся безопасность системы не удастся. Вся цель систем резервирования заключается в защите от процессоров/программ, идущих с трудом. Если ни один из задействованных процессоров/подсистем никогда не пойдет на уступки, зачем вам нужен избиратель большинства? Какая ошибка вы пытаетесь защитить?

• Если A опросов B для голосования и B никогда не отвечает или не отвечает вздором, то что? Этот сценарий должен быть указан в вашей спецификации. Тайм-ауты, обнаружение ошибок, поведение при ошибке и т. Д.

Также считают: «большинство избирателей» - это старая техника модного слова 80-х годов. Это может быть или не иметь смысла: это может улучшить безопасность, или это может быть полная бессмыслица. Имейте в виду проектирование в ложной безопасности и осознавайте опасные «стандарты безопасности», ослепляющие проповедь, чтобы использовать большинство избирателей, не зная специфики вашей системы.

Стандарты «SIL» 61508/26262 могут быть особенно опасны для слепого доверия здесь, так как им не хватает рациональных/современных источников для рекомендации «большинства избирателей». См. Например, IEC 61508-7 A.1.4, это полная бессмыслица: источники - это технические документы, доступные только на немецком языке, начиная с 80-х годов. Смеяться или плакать?

Применение здравого смысла гораздо важнее, чем содержание этих стандартов!

Зачем вам когда-либо хотеть использовать 2 из 3 в критически важной для безопасности системе? Это составляет 33% от сбоя системы, почему вы хотите, чтобы система продолжала работать в таком сценарии? Во многих системах 33% системных сбоев были бы довольно катастрофическими ... Аналогичным образом, «диагностический охват» 66% будет считаться крайне бедным во многих системах.

Весь дизайн системы безопасности действительно зависит от того, что считается безопасным состоянием и что делать с критическим сбоем. Безопасное состояние «останавливает все» (типичное промышленное применение) или оно «продолжает работать/хромать, а также вы в состоянии» (типичное автомобильное/медицинское применение).

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