[Harbinger 10]

Касательно кортексов. Если нужен сверхдешёвый M0, м.б. есть смысл на китайцев посмотреть. У них найдётся даже pin-to-pin 32-битная замена STM8S003, по той же цене.

Например: http://www.hdsc.com.cn/list/73/

Недостаток: документация исключительно на китайском языке.

[jcxz 184]

В 01.02.2019 в 17:41, haker_fox сказал:

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

Это как взял в правую руку ложку, чтоб супа поесть, но не доверяешь ей (руке). И правда - вдруг она мимо рта да в чужой рот суп пронесёт??? 

Тогда мы будем её левой рукой контролировать, придерживать, чтоб правая не своевольничала.   Странная картина вырисовывается, не правда ли?...  

 

В 01.02.2019 в 17:41, haker_fox сказал:

Если менее затейлево выражаться - то для обеспечения двукратного дублирования: канал управления (cortex-m0), канал мониторинга (pic, avr, msp430). При обнаружении ошибок у друг дружки - перевод модуля в безопасный режим.

Чем больше у вас всякого разнообразия в коде, тем больше вероятность ошибок в нём. Так что ваша система будет ещё менее надёжной чем на одном МК.

[jcxz 184]

В 01.02.2019 в 23:40, adnega сказал:

Местный опыт показывает, что бага в 99% случаев программная.

Вот именно. И увеличение числа архитектур в проекте просто сделает её вероятность равной: (1-.01/2) = 0.995 = 99.5%

11 часов назад, novikovfb сказал:

и это прекрасно: вероятность обнаружения бага удваивается, если не будет еще выше, ведь каждый чих будет проверяться.

Конечно хорошо: чем больше багов отловлено, тем больше премий себе любимому можно обосновать перед начальством.  

 

PS: А если серьёзно, то и количество требуемой работы удваивается. Получается что даже если предположить что результирующая вероятность бага стала такой же как в случае с одним МК, то может лучше эту вторую дополнительную половину работы потратить на лучшую проработку основного ПО и получить меньшую вероятность бага?

Тратить время полезно на работу извилин (например: ревью кода сторонним программистом если не доверяете основному), а не на работу пальцев (как можно больше набыдлокодить, авось что-нить и заработает).

[jcxz 184]

10 часов назад, haker_fox сказал:

Задача этого МК мониторить работу "большого брата" (Cortex-M3/M4/M0), и частично разделить с ним управление шаговым двигателем. Вообще, мне кажется, я в теме уже желающим объяснил задачу.

Вангую: через некоторое время Вы создадите тему "порекомендуйте МК, который будет контролировать второй МК, который контролирует третий МК".  

[haker_fox 60]

7 hours ago, jcxz said:

Чем больше у вас всякого разнообразия в коде, тем больше вероятность ошибок в нём. Так что ваша система будет ещё менее надёжной чем на одном МК.

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

7 hours ago, jcxz said:

Вангую: через некоторое время Вы создадите тему "порекомендуйте МК, который будет контролировать второй МК, который контролирует третий МК".

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

Ну и таки да: в Аэрбасе дураки сидят, поскольку в компы ставят две разные архитектуры, две разные схемы, и два разных комплекта ПО, написанных и созданных разными командами (говорю о A320). Боинг же совсем рехнулся: ставят три (три!) разные архитектуры процессоров в один комп, да ещё таких компа имеют три штуки. Если говорить строго, то, конечно авионику не сами эти фирмы создали, а профильные: талекс, rockwell collins, sfena, sextant и другие.

[AndrejM 0]

Для управления критически важными объектами в плане требований к архитектуре и к разработке все уже придумано, и более, как военные уставы написано кровью. Можете изучить соответствующий ГОСТ   МЭК61508 (он же IEC61508), а если решите использовать несколько архитектур то тогда вам еще понадобится МЭК61784, прочитайте там требования к безопасным коммуникационным профилям и оцените надо оно вообще для вашей задачи, или же достаточно будет, к примеру, то же геркулес взять и в рамках одного CU решить. Ну и требования к разработке ПО посмотрите, прежде чем решение принимать, там много сюрпризов типа запрета арифметики с указателями, фактический запрет приведения типов, запрет использования динамической памяти, запрет использования внешних прерываний и.т.д.  Я вас уверяю, что даже после поверхностного изучения темы, ваша альтернатива выбора контроллера уложится в два пальца на руке (ну и третий отказаться от задачи), если вы конечно не представитель корпорации типа Боинга.

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

[haker_fox 60]

@AndrejM, очень интересно пишете! Вы в "этой" области работаете?

5 minutes ago, AndrejM said:

фактический запрет приведения типов

И как без этого быть? Ни одна же программа такого не выдержит...

5 minutes ago, AndrejM said:

запрет использования динамической памяти

согласен 100% !

5 minutes ago, AndrejM said:

запрет использования внешних прерываний

Почему? Как реагировать на внешние события?

 

За документы - спасибо! Сам погляжу и коллегам дам почитать!

 

9 minutes ago, AndrejM said:

то же геркулес взять и в рамках одного CU решить

Понимаете, не я принимаю решение. В данном проекте руководят другие люди, они же платят, и они же разбираются в вопросе. Я лишь могу доверять, ну и... проверять, естественно))) Т.е., понятно, что я почитаю документы. Но геркулес сам себя только мониторит. Но, а если сбой или неисправность произойдёт в схеме, приводе, датчиках?

[jcxz 184]

6 часов назад, haker_fox сказал:

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

Дублирование, когда имеются в виду два идентичных аппаратных блока с одинаковым ПО, конечно же даст увеличение надёжности. За счёт выявления аппаратных сбоев. О программных багах тут речи нет.

Кроме рекомендованных вам выше МК, можете посмотреть также на TriCore: https://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-microcontroller/

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

Цитата

Ну и таки да: в Аэрбасе дураки сидят, поскольку в компы ставят две разные архитектуры, две разные схемы, и два разных комплекта ПО, написанных и созданных разными командами (говорю о A320). Боинг же совсем рехнулся: ставят три (три!) разные архитектуры процессоров в один комп, да ещё таких компа имеют три штуки.

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

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

И Боинг, на который Вы ссылаетесь, имеет всё-таки я думаю несколько иной бюджет на свои разработки. А значит - может вести такие работы на соответствующем уровне. Пытаться впихнуть такое в обычный инвертор для э/двигателя - это значит вместо решения насущных задач, тратить время на какую-то ерунду. И в результате получить заведомо худший результат по сравнению с тем, чтобы всё это время с пользой потратить на основное ПО, его более глубокую отладку. Если у вас есть лишний программист и вам его нечем занять, то лучше посадите его за ревью кода основного программиста. Для такой системы это (имхо) даст лучший результат.

 

PS: Или Вы свой самолёт разрабатываете?  

[haker_fox 60]

7 minutes ago, jcxz said:

а мнению безграмотных писак из СМИ и прочих "диванных спецов" - не доверяю

Общение с коллегами в этой теме дало много пищи для размышления. Также документы с архитектурами систем управления полётом предоставлены обеими фирмами. Так, что здесь никаких домыслов нет)))

13 minutes ago, jcxz said:

Или Вы свой самолёт разрабатываете?

Нет, но если объет будет "повёрнут" шаговиком не туда, куда надо, и не в то время... то стоимость самолёт (ну стоимость его одного сидения из салона) я заплатить буду должен)))

[jcxz 184]

В 01.02.2019 в 21:56, haker_fox сказал:

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

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

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

Также документы с архитектурами систем управления полётом предоставлены обеими фирмами. Так, что здесь никаких домыслов нет)))

Так у Вас система управления полётом? Или всё-таки инвертор? Если последнее - при чём тут Боинг??? Приведите тогда уж примеры инверторов, где применяется резервирование подобное вашему. Если не сможете найти, то подумайте почему их нет.

[haker_fox 60]

22 minutes ago, jcxz said:

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

Сильно сомневаюсь, я думаю есть способ засинхрозировать обе архитектуры.

22 minutes ago, jcxz said:

Так у Вас система управления полётом? Или всё-таки инвертор?

Ни то, ни другое. Систему управления полётом привёл только в качестве примера построения отказоустойчивой системы. У меня модуль управления шаговым двигателем, которому приходят сигналы от неких датчиков (начиная от банальных концевиков), и который, основываясь на данных, полученных с них, должен этим двигателем управлять. Сам двигатель перемещает "некую деталь" в механизме.

[esaulenka 5]

On 2/1/2019 at 2:41 PM, haker_fox said:

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

Задача-то какая? Если это не самолёт, который не умеет зависать в воздухе, и в любой ошибочной ситуации вашему двигателю можно просто никуда не двигаться, надо именно так и поступить.
Максимально тупое устройство (читай - с минимумом ошибок), которое в любой непонятной ситуации всё (или только силовую часть, неважно) обесточивает.

[haker_fox 60]

2 minutes ago, esaulenka said:

Максимально тупое устройство (читай - с минимумом ошибок), которое в любой непонятной ситуации всё (или только силовую часть, неважно) обесточивает.

Ну да, вот и стоит вопрос как это сделать. Есть вариант, и его предлагали тут выше, поставть рядом что-то типа CPLD/FPGA. Кстати-обесточивание не подходит никак! Вернее, можно, если есть привода в резерве. В любом случае привод должен быть всегда готов выполнить команду. И здесь, как самолёт. Хоть и на земле, но последствия тоже хреновые...

[esaulenka 5]

29 minutes ago, haker_fox said:

Кстати-обесточивание не подходит никак! Вернее, можно, если есть привода в резерве. В любом случае привод должен быть всегда готов выполнить команду.

Ну значит сначала надо спроектировать систему.

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

[haker_fox 60]

23 minutes ago, esaulenka said:

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

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