Кто должен определять какие результаты должны совпасть?
Определяете некоторый набор данных и его гоняете между комплектами. Сбойный комплект упал, поднялся, засинхронизировался — все.
Понятно, что вы тут заодно дискутируете на тему «а как синхронизироваться, если надо быстрее», «а если надо еще быстрее» и «а если надо совсем быстро», но тут говорить просто не о чем — надо смотреть конкретные характеристики быстроты синхронизации и частоты сбоев.
Хотя, с высоты диванного полёта мне кажется, что брокера можно реализовать как «голосование электричеством» — если достаточное количество проводов подали сигнал, то устройство срабатывает
Это один из вариантов для некоторых случаев (называется еще «накачкой команды», хотя этот термин больше употребляется в телемеханике), однако системно он проблему не решает.
Ну и потом — ну вот идут три процессора в ногу, а один нет. Положим «токового сигнала» от трех достаточно, ок полетели куда надо. И эти три как-то должны понять, что четвертый охренел, да и сбросить его (иначе на следующем шаге будет уже два несогласных). А он берет — и блокирует сброс, либо у него с обработчиком NMI что-то не то случилось, либо он сам остальных сбрасывать начинает… Тут конечно помогает мажорированный сброс, но в целом это тоже все такое.
Основная проблема состоит в том, что ИРЛ у вас есть какие-от исполнительные устройства, обычно достаточно простые, но выполняющие важные функции (из серии «повернуть налево»). И эти устройства, повторюсь, весьма просты и незатейливы (иначе внутри них самих возникают все те же проблемы), следовательно нужен некий механизм воспрепятствования попаданию на них некорректной команды. И тут как раз пригождается аппаратный TMR или хотя бы Lockstep в рамках центрального вычислителя.
Заменить CAN (а тем более FlexRay) этим вот интерфейсом — сомнительная, хотя и нажористая идея. Вот победить RS-485+Modbus в КИПиА — запросто, протокольный уровень и правда ничем не сложнее, а за новую схемотехнику потребитель все равно заплатит, как уже платит за использование EtherCAT везде, где ни попадя. А вот с заменой I2C опять наркоманство какое-то… Зачем?
А Хартинг пусть сначала научится делать разъемы М12.
Эту штуку нельзя потерять — значит она должна быть ярко-оранжевой и т.п. За десятилетия здесь тоже выработалось множество правил — не даром утюги похожи на утюги, а дрели на дрели
Работа промдиза — одна из самых сложных. Это даже сложнее холиваров в стиле "std::snprintf vs std::to_string", поскольку ну вообще нет критериев, даже взаимные обвинения в неэргономичности выглядят жалко, а уж сравнить красоту вообще невозможно. Мне не показалось, что хотя бы один из "стало" в статье оказался лучше, чем "было", но это лично мое мнение, а вот с чем спорить нельзя — стало более броско, более "на стиле", немного "ай-нанэ", вот это вот все. Это очень странная тенденция на мой взгляд, но она реально рулит миром нынче, так что скорее всего все ваши клиенты от вашей помощи выиграли. Если бы (это я уже к другим комментаторам обращаюсь) конечным потребителям указанных изделий в самом деле было не наплевать на дизайн, а от расположения органов управления в самом деле что-то зависело, то за все эти дизайны руки по самые плечи оторвали бы уже не только авторам статьи, но и их заказчикам (чтобы неповадно было заказывать редизайны). Большинству же заказчиков и конечных потребителей глобально на все плевать, но дизайн радует глаз.
В какой-то древней книжке еще в университете читал, что перед вызовом free обязательно надо проверять указатель, иначе UB. Естественно это может быть в целом ложным утверждением, справедливым только для той конкретной древней книжки и какого-то особенного Си, описанного в ней, но в памяти отложилось навсегда, посему делаю так же всю жизнь…
Ну да, все как всегда — «один знакомый» и квантор всеобщности во все поля. Вот прямо вся страна собирается в кафешечке и играет, никто-никто не протирает штаны в одного.
Определяете некоторый набор данных и его гоняете между комплектами. Сбойный комплект упал, поднялся, засинхронизировался — все.
Понятно, что вы тут заодно дискутируете на тему «а как синхронизироваться, если надо быстрее», «а если надо еще быстрее» и «а если надо совсем быстро», но тут говорить просто не о чем — надо смотреть конкретные характеристики быстроты синхронизации и частоты сбоев.
Это один из вариантов для некоторых случаев (называется еще «накачкой команды», хотя этот термин больше употребляется в телемеханике), однако системно он проблему не решает.
Ну и потом — ну вот идут три процессора в ногу, а один нет. Положим «токового сигнала» от трех достаточно, ок полетели куда надо. И эти три как-то должны понять, что четвертый охренел, да и сбросить его (иначе на следующем шаге будет уже два несогласных). А он берет — и блокирует сброс, либо у него с обработчиком NMI что-то не то случилось, либо он сам остальных сбрасывать начинает… Тут конечно помогает мажорированный сброс, но в целом это тоже все такое.
Заменить CAN (а тем более FlexRay) этим вот интерфейсом — сомнительная, хотя и нажористая идея. Вот победить RS-485+Modbus в КИПиА — запросто, протокольный уровень и правда ничем не сложнее, а за новую схемотехнику потребитель все равно заплатит, как уже платит за использование EtherCAT везде, где ни попадя. А вот с заменой I2C опять наркоманство какое-то… Зачем?
А Хартинг пусть сначала научится делать разъемы М12.
Это другое, я писал про «критерии красоты».
Об этом я по сути и написал. И поскольку эта ситуация всех устраивает — грех ей не воспользоваться.
Работа промдиза — одна из самых сложных. Это даже сложнее холиваров в стиле "std::snprintf vs std::to_string", поскольку ну вообще нет критериев, даже взаимные обвинения в неэргономичности выглядят жалко, а уж сравнить красоту вообще невозможно. Мне не показалось, что хотя бы один из "стало" в статье оказался лучше, чем "было", но это лично мое мнение, а вот с чем спорить нельзя — стало более броско, более "на стиле", немного "ай-нанэ", вот это вот все. Это очень странная тенденция на мой взгляд, но она реально рулит миром нынче, так что скорее всего все ваши клиенты от вашей помощи выиграли. Если бы (это я уже к другим комментаторам обращаюсь) конечным потребителям указанных изделий в самом деле было не наплевать на дизайн, а от расположения органов управления в самом деле что-то зависело, то за все эти дизайны руки по самые плечи оторвали бы уже не только авторам статьи, но и их заказчикам (чтобы неповадно было заказывать редизайны). Большинству же заказчиков и конечных потребителей глобально на все плевать, но дизайн радует глаз.
Об этом и речь — нужен детектор со спектральным разрешением.
Шутка, я сам из Москвы )))