Многофункциональные РУС и РУД

[Дмитрий Шаповалов (Velocity)]

Возникла мысль сделать ручку http://www.infinityaerospace.com/infgrip.htm (собственно не только её, но и похожие) более многофункциональной и "гибкой".
В данной ручке десяток кнопок и не менее 11 проводов (часто нужно больше) для её подключения к самолетной электросистеме. Во первых, такая толщина кабеля меня напрягает с точки зрения механики (изгибать такой кабель не очень желательно). Во вторых, он жестко привязывается к исполнительным механизмам и изменение работы связано с переделкой электросхемы.

Идея состоит в том, что все кнопки в ручке загоняются в контроллер, установленный непосредственно в корпусе самой ручки и контроллер обменивается информацией о состоянии кнопок с электросистемой самолета по двухпроводному двунаправленному интерфейсу. В результате получается что для соединения РУС с электросистемой самолета нужно только 4 провода - 2 электропитание + 2 обмен данными.
Я планирую использовать протокол типа I2C для обмена и контроллеры типа PIC16F876A. В электросистеме самолета будет смонтирован приемник и большее, чем требуется, количество выходов, позволяющее менять функциональность ручек оперативно в полете (при необходимости) или изменением программного кода приемника (при установке/замене дополнительного оборудавания самолета. Это могут быть управляемые фото или видео камеры, оборудование АХР, дымы и т.д.). Таким образом, появляется возможность оперативного изменения конфигурации управления для второго или первого пилота в зависимости от типа выполняемого полета.

 

[Дмитрий Шаповалов (Velocity)]

РУД от infinity тоже имеет довольно большую насыщенность кнопками.

Тянуть пол сотни проводов от 4-х ручек - грустная затея  :IMHO

 

[Commodore]

Надо поставить три контроллера по мажоритарной схеме (два из трёх), а кнопочки подключить к ним через резисторные развязки, исключающие влияние к.з. через сдохший микроконтроллер.

/me

 

[SeregaB]

Идея состоит в том, что все кнопки в ручке загоняются в контроллер, установленный непосредственно в корпусе самой ручки и контроллер обменивается информацией о состоянии кнопок с электросистемой самолета по двухпроводному двунаправленному интерфейсу. В результате получается что для соединения РУС с электросистемой самолета нужно только 4 провода - 2 электропитание + 2 обмен данными.

До этого места все очень здорово.

Я планирую использовать протокол типа I2C для обмена

А вот это ты зря. Если делать, то что-нибудь более приспособленное для этих целей (CAN, LIN etc). Вспомни, что ты писАл здесь

кроме того этот протокол не позволяет по моему работать нескольким устройствам в одной шине, а это  . RS-485 могёт, но это не наш метод  . CAN решает эти проблемы легко

Реально  - пора широрко внедрять CAN в электросхему самолета. И ты должен лучше всех это понимать, поскольку в одном лице хороший пилот и хороший электронщик. Начинать как раз с таких штук.

 

[nico]

Реально- пора широрко внедрять CAN в электросхему самолета. И ты должен лучше всех это понимать, поскольку в одном лице хороший пилот и хороший электронщик. Начинать как раз с таких штук.  

только надо это делать ОБДУМАННО.... сто раз ОБДУМАННО...
CAN как протокол на физическом уровне - весчь надежная, для чего в общем то и создавался . осталось только  логику увязать .. :IMHO
СANopen  forever ;D

вот для общего развития...
http://can.marathon.ru/projects/canschool-02/RU-Betair02.pdf
🙂

 

[GVV]

кроме того этот протокол не позволяет по моему работать нескольким устройствам в одной шине, а это  . RS-485 могёт, но это не наш метод  . CAN решает эти проблемы легко  

 
CAN или ай-ту-си, решать разработчику, но ай-ту-си позволяет работать в "общей шине", при условии, естественно, что все устройства на шине имеют разные адреса.

 

[Дмитрий Шаповалов (Velocity)]

Надо поставить три контроллера по мажоритарной схеме (два из трёх), а кнопочки подключить к ним через резисторные развязки, исключающие влияние к.з. через сдохший микроконтроллер.

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

Кнопки  :IMHO намного менее отказоустойчивы чем микросхемы.

А вот это ты зря. Если делать, то что-нибудь более приспособленное для этих целей (CAN, LIN etc).

Для именно этой задачи достаточно I2C. Как его обработать корректно понимание есть. Добится грантированной безопасной работы не проблема. Из master уже можно и по другому протоколу гонять цифирь, но пока не понятно к каким устройствам. Там на выходе master практически одни контактные группы. Не с кем по сети разговаривать  🙁.

только надо это делать ОБДУМАННО.... сто раз ОБДУМАННО...

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

CAN или ай-ту-си, решать разработчику, но ай-ту-си позволяет работать в "общей шине", при условии, естественно, что все устройства на шине имеют разные адреса.

CAN работает точно так же, и кроме того, аппаратно решает кучу проблем программера, но для этой задачи I2C достаточно.

 

[Commodore]

Кнопки   намного менее отказоустойчивы чем микросхемы.

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

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

/me

 

[Дмитрий Шаповалов (Velocity)]

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

Мне не сложно полностью залить чип компаундом (что и планируется сделать) и во внешнюю среду вывести только контактную группу, а вот защита контактной группы механических кнопок это уже другая песня. Отказов оборудования видел огромное количество и в подавляющем большинстве случаев это были отказы именно электрических соединений. Отказы не силовых электронных компонентов (даже изготовленных не лучшим образом) единичные случаи. У Вас не возникает желания иметь под седушкой самолета обычную запасную ручку с механическими кнопками? Вдруг основная сломается? Посмотрите на вероятные отказы любой из кнопок и поймете, что они практически НИКАК не влияют на возможность дальнейшего продолжения полета.

С Вашей точки зрения (требование повышенной надежности) гораздо адекватнее было бы не вешать на параллельную шину все устройства в сети, а организовать несколько портов, отдельных для каждой ручки, т.к. подвисшая (умершая) в неприятном положении (ноль на выходе slave по CLK или SDA) убъет всю шину. Возможно я так и сделаю.

Мастера наверное буду реализовывать уже на dsPIC30.

ЗЫ. Кроме всего прочего, данная система позволит довольно легко организовать канал удаленного управления оборудованием самолета без серьезной переделки  😉. Для самолетов, конвертируемых в беспилотные системы это будет полезным устройством.

 

[Commodore]

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

Дело абсолютно Ваше - три чипа или один. Чтобы фиксировать уверенное срабатывание кнопок (при наличии довольно больших утечек), надо пропускать через них ток миллиамперного диапазона, что намного превосходит потребление мелкосхем.

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

И куда её вставлять, простите?

С Вашей точки зрения (требование повышенной надежности) гораздо адекватнее было бы не вешать на параллельную шину все устройства в сети, а организовать несколько портов, отдельных для каждой ручки, т.к. подвисшая (умершая) в неприятном положении (ноль на выходе slave по CLK или SDA) убъет всю шину. Возможно я так и сделаю.

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



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

http://www.hpl.hp.com/techreports/tandem/TR-85.3.html


/me

 

[Дмитрий Шаповалов (Velocity)]

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

[media]http://www.youtube.com/v/-s9bz0cEcTg[/media]

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

http://www.hpl.hp.com/techreports/tandem/TR-85.3.html

Репорт 85 года это не очень интересно читать. Нового ничего не видел. Когда писали эти репорты я учился в школе, а эквивалент моего ноутбука занимал огромное здание и по надежности отставал от него на пару порядков. Принципы построения сетей мне известны.

 

[Commodore]

Репорт 85 года это не очень интересно читать. Нового ничего не видел. Когда писали эти репорты я учился в школе, а эквивалент моего ноутбука занимал огромное здание и по надежности отставал от него на пару порядков. Принципы построения сетей мне известны.  

Лучше такого не говорить.  Иначе неизбежно противоречие с самим собой.

БПЛА может отлично летать и на 3-4 мелких 16 разрядных контроллерах с 20-40 мГц тактовыми частотами. Вычислительной производительности будет выше крыши, а стоимость и вес несоизмеримо меньше.  

Действительно, техника в части миниатюризации ушла вперёд, и то, для чего требовался шкаф, сейчас умещается в микросхему. Принципы остались те же. Машины такого типа имеют большой безостановочной работы (одна такая в России "накрутила" уже 12 лет без "трёхпальцевого салюта", и судя по всему, пределом является моральное, а не физическое старение. Слышал про западные 15), применяются в самых критических областях управления (в т.ч. у военных, в управлении воздушным движением, на биржах и т.п.). Посему неплохо подобное задействовать и в бортовых системах (и я полагаю, западные братья по разуму задействовали вовсю).

/me

 

[Дмитрий Шаповалов (Velocity)]

Лучше такого не говорить.  Иначе неизбежно противоречие с самим собой.

И в чем противоречие?

одна такая в России "накрутила" уже 12 лет без "трёхпальцевого салюта", и судя по всему, пределом является моральное, а не физическое старение. Слышал про западные 15

У меня Микрочипы лет 5 без остановки функциклируют. Не о чем это не говорит.

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

Опять же разберитесь насчет критичности отказа конкретной системы в самолете. Всё, что управляется кнопками на РУС или РУД не критично к отказу. Только идиот повесит туда выпуск шасси. Ну отвалится управление внешними видеокамерами или их переключение, ну откажет управление триммером или кнопкой переключения частоты радиостанции. Во первых, половину операций можно выполнить непосредственно с приборной панели, а на вторую половину забить. Городить дублированную систему можно на автопилоте, но нужно ещё очень подумать, приведет ли это к повышению живучести блока управления.

ЗЫ. Commodore я что-то не сильно врубаюсь в Ваши пожелания. Вы бы изобразили схемотехнику, которая Вас устраивает, вмещается в свободное пространство РУС (около 1.5-2 см[sup]2[/sup] максимум, включает разъем для подключения 20 проводов от кнопок и максимум 4-х проводов к панели управления, обрабатывает дребезг контактов, ошибки протокола, дублирует что Вам хочется и не слишком много кушает).

Можете с использованием Linux или Кластеров.

 

[Commodore]

Хорошо. Давайте проясним общие положения.

Безусловно, передачу данных с ручки можно сделать на одном кристалле (как-то не всплыл аргументом таймер защиты от зависания). Имеем простоту и прозрачность. При этом уровень надёжности зависит от исполнения кристалла. Максимум, что можно взять на рынке без удара по карману - чипы исполнения automotive. То есть от -40 до +85 Цельсия (что более чем достаточно) и соответствующая наработка на отказ (ниже чипов military). Над температурным диапазоном мы не властны, а вот надёжность поднять можем. Как? Объединив кристаллы в систему слабосвязанной архитектуры, где каждый модуль будет проверять себя и другие аналогичные модули. Это не "сеть в коробке", это работа с общим полем периферийных устройств и обмен сообщениями о состоянии микроконтроллеров в контрольных точках.

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

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

Надеюсь, я ясно изложил?

/me

 

[Дмитрий Шаповалов (Velocity)]

как-то не всплыл аргументом таймер защиты от зависания

А зачем букварь объяснять?

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

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

Я делаю 5 полностью независимых портов с раздельным питанием для каждого, чтобы зависшее устройство не могло "подвесить" всю шину или убить мастера коротким замыканием. Хардверный модуль работы с шиной I2C заменен на софтовый на мастере и слейве. Похоже, что на PIC16F876A они до конца не реализованы. Методика обработки хардверного I2C мне не понравилась. В принципе для системы допустимо обрубание любого устройства хоть топором. Откажет только действительно умершее внешнее устройство.

При наличии одной шины от мастера к каждому слейву можно поставить 2 независимых чипа параллельно с двумя разными адресами и мастер будет читать информацию с обоих и если один умрет, пользовать данные с резервного, но  :IMHO это излишне. Сделать это нет никакой проблемы.

 

[GVV]

Это не "сеть в коробке", это работа с общим полем периферийных устройств и обмен сообщениями о состоянии микроконтроллеров в контрольных точках.

Думаю, что надёжная работа нескольких контроллеров с общей периферией это труднодостижимый и недешёвый проект. Для понимания этого достаточно ознакомится с реализацией алгоритмов в многоядерных системах. Мне ближе всего опыт по проектированию на двухголовом ЦСП ADSP-BF561(BlackFin). Всякий раз анализируя законченный проект, понимаю, что на борьбу с его "двухбашковостью" уходит уйма времени и сил. Работа с асинхронной периферией требует создания отлаженной системы семафоров (тех самых контрольных точек для обмена сообщениями) иначе начинает лавинообразно нарастать латентная задержка. Иными словами, ядра тормозят друг друга. Ведь они работают не только с общей периферией датчиков, но и исполнительных устройств. Есть ли смысл создавать себе самому трудности, чтоб потом их побеждать. Да и задачка вроде не требует того. "Тщательнее", как говорил Жванецкий, поработать с watch-dog таймером, поставить толковый супервизор и адекватная ситуации надёжность видимо будет достигнута и с одним вычислителем.

 

[Дмитрий Шаповалов (Velocity)]

Да и задачка вроде не требует того.

Согласен, но умным хочется поизголяться. Майнфреймы, кластеры, цифровое поле боя, Линукс, многозадачность, мажоритарная схема, слабо связанная архитектура, почти как у Пушкина Александра Сергеевича, а надо было просто зубочисткой поковырять  ;D. Правда это банально  🙁 никакой поэзии, тупо кодирование программы  :'(

 

[Commodore]

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

Можно до хрипоты спорить, что лучше - брить зад или чесать подбородок, но, как показывает практика, для достижения полезного результата всё надо делать с точностью до наоборот.

http://www.engin.umd.umich.edu/vi/w3_workshops/VI_winter04_guo.pdf

http://www.engin.umd.umich.edu/vi/publications/richardson/richardson_00_ic3n_FTLAN.pdf

/me

 

[GVV]

Мне кажется, джентльмены должны немного поинтересоваться теорией ... Сложностей там особых нет.  

Это вообще то одна из характерных черт теории - отсутствие сложностей. На то она и теория. Сложности обычно бывают на/в практике. Отчасти именно поэтому именно она и является "критерием истины". 😉

 

[Дмитрий Шаповалов (Velocity)]

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

Джентельмены теориями вероятности и распределенных систем интересовались. Сложности там есть.

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

Чтобы не тратить попусту байты ПОЖАЛУЙСТА набросай схему девайса, который как ты считаешь удовлетворяет решению поставленной задачи. Конкретную схему и скелетный алгоритм работы.