[esaulenka 5]

Ну так элементарно же. В боинге ломается один из каналов - некое магическое отказоустойчивое устройство переключает работу на резервный, полёт продолжается.

В вашем изделии ломается один из контроллеров - шаговик встаёт (или ползёт в непредсказуемую сторону).

[jcxz 184]

21 минуту назад, esaulenka сказал:

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

Во-во!

А ещё ТС не понимает, что бюджет времени на разработку - он всегда ограничен. И если скажем на работу выделено N программисто-часов можно:

1. Или потратить все N на разработку одного ПО. Получив надёжность этого ПО прямо пропорциональную потраченному времени, скажем: k*N.
2. Или потратить 0.33*N времени на разработку одного ПО + 0.33*N времени на разработку второго ПО + 0.33*N на согласование действий двух (групп?) программистов. Получив результирующую надёжность всей системы ПО: MIN(k1*0.33*N, MIN(k2*0.33*N, k3*0.33*N)). Где коэффициенты k1/k2/k3 будут зависеть от профессионализма разных разработчиков. Но общую надёжность системы в любом случае определит самая ненадёжная её часть.

8 минут назад, haker_fox сказал:

Нисколько не сомневаюсь в вашем тезисе, но откуда получена "бОльшая" вероятность?

Вы почему-то решили что баги в двух разных ПО будут объединяться по принципу ЛОГИЧЕСКОГО И. С чего бы это? Я вот считаю что они будут объединяться по принципу ЛОГИЧЕСКОГО ИЛИ.  

[haker_fox 60]

1 hour ago, esaulenka said:

В вашем изделии ломается один из контроллеров - шаговик встаёт

Ну и что? Таких блоков + приводов будет несколько. Один (блок, привод) выйдет из строя, а другие останутся. Одновременный выход всех - маловероятное событие.

2 hours ago, jcxz said:

А ещё ТС не понимает, что бюджет времени на разработку - он всегда ограничен.

Поделитесь, пожалуйста, на каком основании вы ставите мне такие диагнозы, да ещё и удалённо? Скажу по секрету - мне это и понимать не нужно. Я уже говорил, что автор проекта не я. Моя задача - в контексте данной темы - выбрать МК. Критерии я дал довольно подробные в первом сообщении темы.

2 hours ago, jcxz said:

Вы почему-то решили что баги в двух разных ПО будут объединяться по принципу ЛОГИЧЕСКОГО И. С чего бы это? Я вот считаю что они будут объединяться по принципу ЛОГИЧЕСКОГО ИЛИ.

Баги в двух разных ПО будут разные, потому, что написаны разными людьми с использованием разных языков программирования. Вероятность "одинаковых" багов, когда, например, оба МК начнут выдавать импульсы правильной фазировки на обмотки - довольно низка. Если один из МК "увидел", что его "сородич" пытается управлять двигателем не в том режиме, не в то время и не в том месте, то он "мгновенно" примет меры: перезапустит обоих, отключит весь блок из работы, пержгёт предохранитель в цепи питания и т.п. Другие блоки с приводами останутся в рабочем режиме. Никак не могу понять, что здесь может быть плохо в такой архитектуре? Ключевое слово - независимость: как программная, так и аппаратная. Оба канала объединяет только один корпус, внутри разделённый перегородкой.

[jcxz 184]

4 часа назад, haker_fox сказал:

Поделитесь, пожалуйста, на каком основании вы ставите мне такие диагнозы, да ещё и удалённо?

Я же указал основание. Посмотрите мои два пункта из сообщения выше. Про бюджет времени == N ч/часов.

Если на одно ПО потрачено N ч/часов, а на другое N/3 ч/часов (при том что сложность ПО примерно одинакова; хотя это неверно - во втором случае ПО будет много сложнее и соответственно ситуация будет ещё хуже), то какое ПО будет надёжнее? Или Вы не согласны с этим?  

Цитата

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

Но автор данного треда ведь Вы? 

Цитата

Никак не могу понять, что здесь может быть плохо в такой архитектуре?

Вот когда начнёте делать, тогда и поймёте.  

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

А самое веселье начнётся когда начнёте отлаживать этого многоголового Змея Горыныча. И когда ваш девайс будет периодически изредка глючить на объекте по непонятным причинам, а оба "независимых" разработчика станут дружно показывать пальцем друг на дружку "У меня всё работает, это в его части сбои". И так будет со 100%-ной вероятностью. Даже когда ПО одно единое, но делается командой, то и в этом случае возникают такие ситуации (не раз сам с таким сталкивался), когда каждый говорит что "у меня всё работает". Так что вам к двум "независимым" разработчикам придётся нанимать ещё и "независимого" третейского судью для разруливания таких ситуаций.  

Вот тогда и вспомните "что плохого".....

 

PS: Главная мысля, которую я хотел донести: Надёжность ПО (и устройства) зависит прямопропорционально от количества времени потраченного на него, и обратнопропорционально - от размера и сложности ПО. Вы же хотите уменьшить это время, усложнить ПО и при этом почему-то получить бОльшую надёжность. Вот это и странно...  

[haker_fox 60]

6 minutes ago, jcxz said:

Или Вы не согласны с этим?

Не согласен. Потому что можно (да так и планируется) увеличить количество человек,занимающихся ПО. Тогда все N часов будут потрачены на Y программ.

8 minutes ago, jcxz said:

Но автор данного треда ведь Вы?

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

11 minutes ago, jcxz said:

Или Вы и с этим не согласны?

Согласен.

11 minutes ago, jcxz said:

Даже когда ПО одно единое, но делается командой, то и в этом случае возникают такие ситуации (не раз сам с таким сталкивался), когда каждый говорит что "у меня всё работает".

Ну тогда для "змея горыныча" ничего не меняется: будут ли программисты одного ПО тыкать в друг друга пальцем, либо независимых программ.

 

12 minutes ago, jcxz said:

Так что вам к двум "независимым" разработчикам придётся нанимать ещё и "независимого" третейского судью для разруливания таких ситуаций.

Это уже точно не моя забота.

[jcxz 184]

26 минут назад, haker_fox сказал:

Не согласен. Потому что можно (да так и планируется) увеличить количество человек,занимающихся ПО. Тогда все N часов будут потрачены на Y программ.

Вы мои посты вообще читаете?

Тогда если ПО одно, то на него можно потратить N*Y ч/часов и получить более надёжное ПО. Просто распилив например на более мелкие части.

Цитата

Ну тогда для "змея горыныча" ничего не меняется: будут ли программисты одного ПО тыкать в друг друга пальцем, либо независимых программ.

Меняется и очень сильно. Потому что когда ПО одно общее, хоть и делается по частям, командой, любому члену этой команды, проще разобраться в чужой части (а это делать придётся в таких ситуациях), чем ковыряться в другом ПО, другой архитектуре, да ещё и другом инструментарии разработки/отладки.

Цитата

Это уже точно не моя забота.

Когда такое случится и к вам придёт начальник и скажет "Давай-ка садись, разберись как у твоих соседей построен проект и найди у них баг". Вот тогда и станет вашей.  

Ну или ваша телега, запряжённая раком, лебедем и щукой, никуда не уедет.  

 

PS: "Это уже точно не моя забота." - да уж, странная у вас там обстановка. Если разработчиков не волнует будет ли работать устройство или нет.....  

 

PPS: И ещё один весёлый пункт в таком Змее Горыныче: Когда (вдруг) уволится разработчик ПО для одной из его голов, то оставшемуся бедолаге представится весёлая возможность изучать и разгребать оставленное ушедшим коллегой "наследство", вникая во все тонкости архитектуры и инструментария. И уволится он в самый такой неудобный момент, когда известно что где-то есть плавающий баг, но неизвестно где  

[Ruslan1 16]

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

:)

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

[haker_fox 60]

18 minutes ago, Ruslan1 said:

Это я к тому, что повышение надежности подобным образом (разные архитектуры, разработчики и т.д.) - антинаучно.

Это вы сами придумали или являетесь специалистом в данной области?

[Михась 2]

Есть книга Федоров Основы построения АСУТП взрывоопасных производств, может быть вам она будет полезна.

[AlexandrY 3]

52 minutes ago, Ruslan1 said:

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

Действительно, можно  взять разных типа разработчиков, а они будут юзать одни и те же либы C-и из какого-нить опенсорса.
Скажем для управления движками открытых проектов на пальцах пересчитать, хороших вообще один два, вероятность почти 100% что народ заюзает одно и тоже.
Компиляторы бесплатные тоже будут  типа разные, а на самом деле все на одном и том же GCC.
Программеры тож как бы разные, а читать будут одни и те же книжки типа "трюки на С".

Т.е. минимум программеры должны говорить на разных языках и желательно одна группа должна быть из Китая где запрещен гугли 

 

     

 

[Arlleex 131]

Ничего странного в независимом дублировании не вижу.

Читал где-то, что в ракетоносителях 20-летней давности применяли такой подход. Боинг вроде тоже так делают.

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

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

Так что мысли haker_fox вполне даже материальны.

 

Но вот если чисто мое мнение - десятикратное резервирование не поможет при кривом ПО или железе. Например, сгорит ключ в двигателе поворотной колонны и замкнется чистым КЗ. Он разгонится и снесет кому-нибудь голову. Поможет тут резервирование? Думаю, что нет. ИМХО, в таком случае нужно думать о резервировании разной природы - например электроника + механика.

[AlexandrY 3]

1 minute ago, Arlleex said:

Читал где-то, что в ракетоносителях 20-летней давности применяли такой подход. Боинг вроде тоже так делают.

А что дает основания два чипа сравнивать с независимыми электронными блоками? 
Тогда чипы нужно взять тоже не меньше чем SoC чтоб аналогия работала.  

Еще надо помнить, что боинги должны работать по 20 лет, за такое время многие фирмы уходят в небытие. 
Вот боинг и страхуется, чтоб был кто на поддержке через 20 лет.  Т.е. это совсем другая тема. 

[haker_fox 60]

35 minutes ago, AlexandrY said:

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

Это регулируется административными документами. Один из языков программирования - ассемблер. Тут трудно найти какие-то либы)

23 minutes ago, Arlleex said:

например электроника + механика

Согласен с вами на 100% !!! Об этом и речь! Не только блоки управления имеют внутри два канала, но и самих блоков с приводами несколько.

[haker_fox 60]

12 minutes ago, AlexandrY said:

А что дает основания два чипа сравнивать с независимыми электронными блоками? 

Пусть количество ошибок не уменьшится, но их "природа возникновения" будет разной, что уменьшит вероятность выхода из строя всего блока.

 

13 minutes ago, AlexandrY said:

Вот боинг и страхуется, чтоб был кто на поддержке через 20 лет.  Т.е. это совсем другая тема. 

Ну mc68040 вроде как до сих пор можно купить))) А на нём летаеют))) Ну, а про страхование - не согласен. Из их тройки (см. рисунок) просто так ничего не выкинуть.

[Obam 30]

Обратите внимание: межпроцессорный обмен и напрямую, и по ARINC.