Горячее резервирование

Цитата:

---

Сообщение от Вольд

Это смотря какая задача у автора темы.

---

Совершенно согласен. Разумеется так.

Цитата:

---

Сообщение от Ryzhij

Простите, но давайте всё-таки различать "надёжность" и "безопасность"..

---

Давайте. Только вот какая конечная цель надёжности ? Надёжность ради надёжности ? Смысл ?
Зачем нужно надёжное непрерывное управление ? Чтоб просто было ?

Цитата:

---

Сообщение от KSergey

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

---

Вы собираетесь примитивным Watch Dog'ом диагностировать отказ контроллера? Это никак не повлияет на надёжность системы. Да ещё не охватывая дублированием периферию? Вы считаете контроллер самым слабым звеном - на каком основании? Выход из строя любого модуля расширения сведёт всё на нет. А датчики? Нередко именно они - слабое звено. Даже если вы полностью продублируете систему вместе с периферией, это нисколько не повлияет на статистику отказов. Простой пример - у вас одна система измерила температуру и получила 100°С, другая получила 120°С. Какая из них врёт? Ваш Watch Dog сможет определить? Нет? Тогда это влечёт за собой включение третьей системы, арбитра. Которая будет полностью повторять вычисления первых двух, основываясь на данных от собственных датчиков, и по мажоритарной системе определять слабое звено. Т.е. три системы молотят одновременно, в случае совпадения результатов всё ОК, работаем дальше, если результаты разошлись, определяем виновника путём голосования, отключаем его и продолжаем работу, сигнализируя сервисной службе об отказе системы, если все три результата не совпали - запускаем на арбитре программу аварийного завершения работы оборудования.
Потом обнаруживаем недостатки и у этой системы. Добавляем четвёртый контроллер. Потом пятый.
Теперь представим себе стоимость подобной системы. Это у вас управление атомным реактором? Самолётом? Может быть, стоит отказаться от этой затеи? Кстати, ведь надёжность системы зависит ещё и от количества звеньев системы, и их увеличение отнюдь не увеличивает надёжность. Вот намедни рухнул ТУ-95, отказ трёх двигателей. На какие мысли это наводит? Может быть, например, что отказал клапан переключения топливных баков? Смысл тогда в таком резервировании?
А вообще лучше начать с изучения теории надёжности. Всё уже придумано до нас. Очень поучительна в этом смысле история завершения полётов Spase Shattle, в особенности результаты расследования крушений челноков. Весьма занимательно об этом описано Фейнманом, нобелевским лауреатом по физике, участником комиссии. Там как раз речь шла о бортовых вычислительных системах. К концу программы они весьма устарели, а их модернизация влекла за собой полный цикл испытаний, стоимость которого приближалась к затратам на разработку с нуля совершенно нового корабля.

Цитата:

---

Сообщение от Ryzhij

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

---

Цитата:

---

Сообщение от Валенок

Давайте. Только вот какая конечная цель надёжности ? Надёжность ради надёжности ? Смысл ?
Зачем нужно надёжное непрерывное управление ? Чтоб просто было ?

---

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

Цитата:

---

Сообщение от Ryzhij

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

---

Вот тута соглашусь.
Тока не всегда резервирование приводит к снижению издержек.
Где-то близко : Как-то летел на ПНР. Со мной туда же летели коллеги на "параллельный" ПНР. Поговорили. Когда узнали что у меня автоматика на овне - сниходительно посмеялись. У них было на Ми-си. После рассказали куда они обычно там ходят на ужин..

Цитата:

---

Сообщение от Eugene.A

Вы собираетесь примитивным Watch Dog'ом диагностировать отказ контроллера? Это никак не повлияет на надёжность системы. Да ещё не охватывая дублированием периферию? Вы считаете контроллер самым слабым звеном - на каком основании? Выход из строя любого модуля расширения сведёт всё на нет. А датчики? Нередко именно они - слабое звено. Даже если вы полностью продублируете систему вместе с периферией, это нисколько не повлияет на статистику отказов. Простой пример - у вас одна система измерила температуру и получила 100°С, другая получила 120°С. Какая из них врёт? Ваш Watch Dog сможет определить? Нет? Тогда это влечёт за собой включение третьей системы, арбитра. Которая будет полностью повторять вычисления первых двух, основываясь на данных от собственных датчиков, и по мажоритарной системе определять слабое звено. Т.е. три системы молотят одновременно, в случае совпадения результатов всё ОК, работаем дальше, если результаты разошлись, определяем виновника путём голосования, отключаем его и продолжаем работу, сигнализируя сервисной службе об отказе системы, если все три результата не совпали - запускаем на арбитре программу аварийного завершения работы оборудования.
Потом обнаруживаем недостатки и у этой системы. Добавляем четвёртый контроллер. Потом пятый.
Теперь представим себе стоимость подобной системы. Это у вас управление атомным реактором? Самолётом? Может быть, стоит отказаться от этой затеи? Кстати, ведь надёжность системы зависит ещё и от количества звеньев системы, и их увеличение отнюдь не увеличивает надёжность. Вот намедни рухнул ТУ-95, отказ трёх двигателей. На какие мысли это наводит? Может быть, например, что отказал клапан переключения топливных баков? Смысл тогда в таком резервировании?
А вообще лучше начать с изучения теории надёжности. Всё уже придумано до нас. Очень поучительна в этом смысле история завершения полётов Spase Shattle, в особенности результаты расследования крушений челноков. Весьма занимательно об этом описано Фейнманом, нобелевским лауреатом по физике, участником комиссии. Там как раз речь шла о бортовых вычислительных системах. К концу программы они весьма устарели, а их модернизация влекла за собой полный цикл испытаний, стоимость которого приближалась к затратам на разработку с нуля совершенно нового корабля.

---

самым "слабым звеном" в системе которую проектирует человек, задавший обсуждаемый вопрос, является программа которую он пишет )))) поэтому перекидывание процесса на другой контроллер, пока первый висит до ватчдога вполне решит задачу )))

То о чем написал автор темы в своем первом посте не является классическим горячим резервированием. То что он хочет (если один ПЛК отказал, то управление берет на себя резервный ПЛК) легко реализуется на оборудовании ОВЕН. Не понятно из-за чего весь сыр-бор вдруг разгорелся. krollcbas, вы первый пост в теме внимательно читали ?:eek:

Дьявол, как всегда, в деталях.
Что топик-стартер подразумевает под "управление берет на себя резервный ПЛК"?
А что происходит с технологическим объектом во время перехода?
У термина "горячее резервирование" есть вполне определённое содержание, так же как и у понятия "тёплый резерв".
Так что ХЗ, что имеет ввиду топик-стартер.

Все намного проще. Автор темы использовал выражение горячее резервирование для солидности и кое кто на это повелся.:D