Отказоустойчивая архитектура диспетчеризации

[mf_]

Добрый день.
Прошу возместить пробелы в знаниях.
Как я сейчас вижу отказоустойчивость АСУТП:
дублирование датчиков, резерв исполнительных механизмов (где возможно), резерв каналов ввода-вывода, горячий резерв ПЛК, горячий резерв SCADA оператора, резерв интернет-соединения, горячий резерв SCADA диспетчера.
Что ещё необходимо? Возможно, нужно выносить базы данных куда-то отдельно?
При резервировании интернет соединения, есть возможность (программная или железная) переключения без задержки?
При горячем резервировании ПЛК, как определяется выход из строя основного контроллера для автоматического переключения на резервный?
Спасибо.

[leon78]

Надо смотреть ваши требования. И схему структурную. Возможно, вам надо основной и резервный ПЛК разносить на расстояние 20 км и основной и резервный диспетчерский пункты организовывать в разных городах

Отправлено спустя 10 минут 42 секунды:

При горячем резервировании ПЛК, как определяется выход из строя основного контроллера для автоматического переключения на резервный?

https://www.reallab.ru/bookasutp/8-appa ... vanie-plk/

[Бондарев Михаил]

Возможно, вам надо основной и резервный ПЛК разносить на расстояние 20 км

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

[muZZy]

Ну что ж, продолжу “набивать» «карму»:
ТС, Вы студент? Ибо вопрос выглядит именно таким образом (хотя конечно вопрос хорошего студента)
Резервирование далеко не дешевое удовольствие, следственно никто «добровольно» реализовывать это не будет.
Поскольку указанные эманации выполняются исключительно принудительно, соотвесвтенно должен существовать некий источник принуждения – требования «НТД»
Я в курсе, что НТД не указывают «как», но типо устанавливают «что» требуется реализовать.
Далее возникают некие «частные» вопросы «привязанные» к конкретным условиям…

Собственно в чем заключается Ваш вопрос?

[Jackson]

Как я сейчас вижу отказоустойчивость АСУТП:

Давайте сначала. С самого.

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

Во-2-х - отказоустойчивость ЧЕГО? Какой конкретно подсистемы? Или всего объекта? Ответ на это вытечет из "во-первых" и не раньше.

В-3-х, в общем и целом, отказоустойчивость - это устойчивость к одиночным отказам. Есть определение, точнее требование, в разных нормативах оно звучит по-разному, но суть примерно такая: одиночный отказ в такой-то системе не должен оказывать влияния на работу объекта (а не этой системы!). Т.е. система может и сдохнуть - главное чтобы объект при этом продолжал непрерывно работать.

Так что сначала уточняйте "во-1-х" и "во-2-х" - только потом будем разговаривать дальше.

[+] ибо очень по-разному может достигаться эта отказоустойчивость

Например,
Дано: атомный энергоблок, не скажу какой.
Есть вспомогательная электростанция, которая состоит из

• генераторные агрегаты
• ГРЩ
• вторичные распределительные щиты ответственных потребителей
• САУ ГРЩ
• аварийный генератор
• АРЩ (аварийный распределительный щит)
• САУ АРЩ

Задача: обеспечить отказоустойчивость объекта. А это ядрёный реактор с кучей ответственных вспом.механизмов. Да ещё и плавучее это всё. Представляете себе ответственность? Отказоустойчивость САУ (только два компонента из всех перечисленных) тут никого не интересует - главное чтобы вокруг реактора и в операторской всё было в порядке, с САУ или без ней - вообще всё равно.

Решение: четырёхкратно (!) резервируем абсолютно всё перечисленное. Включая РЩ и сами ответственные потребители. Включая помещения. Включая кабели. Включая вообще всё. То есть делаем такой комплекс, а потом делаем ещё три таких же, и ставим все один за другим на фундамент.

При этом нужно ли обеспечивать отказоустойчивость САУ? Как-то особенно - нет. А зачем? Отказ САУ приведёт к отказу одного генератора (по общим нормам он и так резервирован вторым генератором в комплексе), или к отказу всего ГРЩ, или АРЩ. Но у нас уже есть резервирование вспом.электростанции. Разные даже помещения, топливохранилища - всё отдельно своё. И в случае, не дай бог, форсмажора, вот это всё запустится разом. Независимо от соседних комплексов. Если хотя бы один из четырёх комплексов отработает штатно - всё в порядке, а их четыре. А если не отработает ни один - это означает наличие такого п..ца, что уже всё равно что и сколько раз у Вас там зарезервировано. Это значит все 4 здания физически разрушены, и это уже не штатная работа, а ЧС всегосударственного масштаба.
А Вы про резервирование контроллеров. :) Да их оба (и основной и резервный) снесёт одним махом.

Вывод: нельзя говорить слово "отказоустойчивость" просто так. Оно не висит в воздухе. Это свойство не АСУ, не прибора, не комплекса, а вообще всего объекта, цеха, здания. И рассматривать и выбирать способ её обеспечения нельзя в отдельно взятой АСУ - нужно смотреть на весь объект.

Подход к рассмотрению темы понятен?

Мер обеспечения - много и все они разные. И не самым плохим иногда оказывается очень простой метод - отсутствие АСУ. :) Нет АСУ - нет элемента ненадёжности - нет проблемы.

Ждём уточнения.

[mf_]

ТС, Вы студент? Ибо вопрос выглядит именно таким образом (хотя конечно вопрос хорошего студента)

Спасибо.

Собственно в чем заключается Ваш вопрос?

Во-1-х - зачем Вы на неё (отказоустойчивость) смотрите? Вопрос на зачёт, объект с требованием, что-то ещё? Оригинал требования - в студию. С описанием места (объекта), к которому это требование предъявляется.

Значит есть объект - городской водозабор, - автоматизация и диспетчеризация которого была сделана в 2008 году немного странным образом. Например, дублирование датчиков давления есть, а резервирования ПЛК нет, резервирование насосов есть, а ЧРП - нет, резервирование SCADA диспетчера есть, а резервирования SCADA оператора и интернет канала - нет.
Соответственно, периодически определённые неполадки приводят к останову, продолжительностью от 40 минут до нескольких часов.

Во-2-х - отказоустойчивость ЧЕГО? Какой конкретно подсистемы? Или всего объекта?

И тут вы, товарищи, совершенно правильно натолкнули на мысль, что резервировать нужно не всё подряд, а в первую очередь то, что чаще даёт сбои. В конкретном случае это нестабильное электропитание и частые обрывы сети интернет.

Отправлено спустя 3 минуты 13 секунд:
Хотя, ПЛК, ЧРП и SCADA оператора, я бы тоже зарезервировал бы.

Отправлено спустя 6 минут 11 секунд:
PS. ТЗ нет. Нужно писать.

[Михайло]

Соответственно, периодически определённые неполадки приводят к останову, продолжительностью от 40 минут до нескольких часов.

Задумайтесь. Если вот это выше - норма, то отказоустойчивость с автоматическим переключением на резерв за 1 мс - это уже лишнее.

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

[Jackson]

Значит есть объект - городской водозабор, - автоматизация и диспетчеризация которого была сделана в 2008 году немного странным образом.

Опять стоп-стоп-стоп.
В главных, усвойте (я рекомендую, а не поучаю) одну фундаментальную вещь. Если Вы не понимаете другого человека (что он сделал), то скорее всего "странный" не он, а как раз Вы. Он-то сделал и что-то понимал, а Вы сейчас не понимаете. Как так: не понимаете Вы, а кто понимает - он "странный". :) Поймите сначала, а потом уже можно говорить, странно там или нет. И при всех прочих, у того "странного" есть громадное преимущество: он сделал и оно работает. Не совсем пусть корректно, но работает, вода людям поставляется.
Ничего личного. Но это фундаментальная вещь, отсутствие которой вообще очень портит всю жизнь и Человеку и всему окружению и работе, и мешает учиться и познавать.

[+]

Коротко это звучит так: Если ты кого-то не понимаешь, то дурак скорее всего не он, а ты. Не понимаешь-то ты, почему тогда дурак - он? Он как раз понимает. В отличие от тебя.

Например, дублирование датчиков давления есть, а резервирования ПЛК нет,

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

резервирование насосов есть, а ЧРП - не

Объяснение то же.

резервирование SCADA диспетчера есть, а резервирования SCADA оператора

А зачем резервировать клиента? Это просто вопрос. Зачем? Цель какая?
Опять же, там резервировано управление целиком. Можно выключить СКАДА и управлять кнопками, переключателями, глядя в приборы на БЩУ. СКАДА - только отображение, те же кнопки, переключатели и приборы, просто на экране.

и интернет канала - нет.

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

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

Нет, не на эту мысль мы Вас толкаем.

Я Вам выше привел пример с атомной установки, где не резервировано вообще ничего - ни ПЛК, ни интерфейсы, ни датчики, ни СКАДА. :) И это работает, очень будоражит половину мира, не сходит с новостей уже лет 15, его даже бомбить пытались и диверсии устраивали - а оно работает. Назвать объект или догадаетесь? :) А там люди не хухры-мухры это всё просчитывали. Куча контор по всему миру, включая МАГАТЭ. Они что - все "странные" ? Почему там сделано именно так? Когда я занимался этим - я понял. На это ушел не один месяц. Вот и у Вас также. Надо просто понять. Сначала изучайте перечисленные в начале вещи. Потом можно будет рассуждать об отказоустойчивости, и не раньше. Изучение тоже за секунду не случится, таблеток знаний ещё не изобрели.

Хотя, ПЛК, ЧРП и SCADA оператора, я бы тоже зарезервировал бы.

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

Отправлено спустя 41 секунду:

Задумайтесь. Если вот это выше - норма, то отказоустойчивость с автоматическим переключением на резерв за 1 мс - это уже лишнее.

Главный вопрос: где и зачем?

Я делал системы, где 1 мс - как раз очень критично. Делал такие где 2 часа - устраивает. А делал и такие, где оно не нужно совсем.

Три волоса - это мало или много? На голове - мало. А в супе - много.

[petr2off]

Работал я с комунальщиками. Или у нас другие комунальщики, но они как то к этому проще относились.
У КНС, для которой я писал программу было 5 насосов, включенных паралельно. Контроллер кстати был Контар - московского завода автоматики, он им так понравился - что они стали выносить Сименсы и ставить его. Конечно Сименс надежнее и ломается раз в 1000 лет, а Контар раз в 100 лет - но их это почему то устраивало.
Пока мы пускали АСУ ТП, КНС уже работала. Они завели туда слесаря дежурного, и он периодически (раз в 2 - 3 часа) включал 1 - 2 насоса через кнопки. Потом заработала наша панель, и он просто сидел там. А потом заработал удаленный АРМ и слесаря убрали.
И им нафиг не надо было дублирования контроллеров, АРМов и всего прочего. Потому как заменить контроллер или панельку - это полчаса работы, со склада дольше вести) .
Точнее - у них есть мощный механизм резервирования - дежурный слесарь. И система в целом сильно отказоустойчивая.
Единственную задвижку на входе они вручную открыли и оставили в ручном режиме. И штурвальчик сняли, что бы никому мысль такая в голову не пришла, повертеть его.
Вот не замарачиваются ребята, и в общем то все работает. Основной элемент отказов у них - гнилые сети водоснабжения и канализации.
И подход их в общем то правильный, нет у них задачи построить супер надежную систему АСУ ТП, потому как к их проблемам это отношения не имеет вообще.

[I_m]

В конкретном случае это нестабильное электропитание и частые обрывы сети интернет.

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

А вообще, резервирование каналов Сети - это самое простое (уточнение - технически самое простое) из того, что Вы тут расписали. Вот только

При резервировании интернет соединения, есть возможность (программная или железная) переключения без задержки?

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

[petr2off]

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

Решения есть всякие. Можно оптическое кольцо сделать на Moxa например - перенастройка маршрута там 300 милисекунд.
Есть вариант резервирование линий PRP, там задержки нет совсем - потому как по факту это дублирование. Можно много что придумать, вопрос зачем ?
Если гнилые трубы рвутся раз в неделю, то отказ сети раз в 3 года - его даже не заметят.

[mf_]

В главных, усвойте (я рекомендую, а не поучаю) одну фундаментальную вещь.

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

Задумайтесь. Если вот это выше - норма, то отказоустойчивость с автоматическим переключением на резерв за 1 мс - это уже лишнее.

Совсем не норма.

Точнее - у них есть мощный механизм резервирования - дежурный слесарь.

Здесь, конечно, тоже есть, но его хотят убрать.

А зачем резервировать клиента? Это просто вопрос. Зачем? Цель какая?

Не уверен, что мы друг-друга правильно поняли. При сбое оператор ждёт 40 минут пока загрузится система (вот такая кривая реализация).

[I_m]

Решения есть всякие. Можно оптическое кольцо сделать на Moxa например

Я отвечал на вопрос о резервировании Интернет-соединений в общем случае. Оптические кольца и RPR тут мимо кассы.

[Jackson]

Здесь, конечно, тоже есть, но его хотят убрать.

Зря. :) Но ничего. Денёк без воды посидят - вернут.

Не уверен, что мы друг-друга правильно поняли. При сбое оператор ждёт 40 минут пока загрузится система (вот такая кривая реализация).

А БЩУ с кнопками и переключателями - что, отсутствует? И локальные посты управления - тоже? Не верю.

Отправлено спустя 3 минуты 2 секунды:

Я отвечал на вопрос о резервировании Интернет-соединений в общем случае.

Это понятно. Но его резервировать нет смысла потому что интернет - это как вселенная. Миллион факторов на него влияет. Левая пятка практиканта в РКН что-то захотела - и положили половину рунета, выругались, починили, но не всё - и никому ничего не сказали. И вот как Вы на это повлияете? :)
Такой объект должен нормально работать и без интернета. Когда он есть - хорошо. Но когда его нет - это не должно быть проблемой.

Отправлено спустя 5 минут 2 секунды:

Спасибо, поставили мою голову на место.

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

[mf_]

Я искренне рад, если это действительно так.

Да, я тоже без сарказма.

А БЩУ с кнопками и переключателями - что, отсутствует?

Не додумывайте за других, я такого не говорил.

[I_m]

Но его резервировать нет смысла потому

Смысл есть. У нас в центре каналы резервированы. По физически разным ВОЛС от разных провайдеров. На периферии в нашем случае смысла в резервировании особого нет, т.к.

Такой объект должен нормально работать и без интернета.

Без связи, если точнее. Но сам факт отсутствия связи является отказом в любом случае.

[Jackson]

Не додумывайте за других, я такого не говорил.

Это был просто вопрос.

Отправлено спустя 31 минуту 11 секунд:

Без связи, если точнее. Но сам факт отсутствия связи является отказом в любом случае.

Нет. Отказом является только то, что влияет на работу объекта. Если точнее - посмотрите нормативы, найдите определение "отказ". Соответственно если не гонять через интернет управление - его отключение отказом не будет являться. Выдумывать не надо - надо открыть норматив и прочитать определение.

Масштабом поменьше пример. Водонапорная башня в деревне. Забор, насос, датчик уровня, предельные датчики нижнего и верхнего уровня, задвижки на вход, на выход. Вся автоматизация - штук десять обычных реле, не нужен контроллер. Щёлкает, ёмкость опустошается и наполняется, всё хорошо. Но приляпали контроллер с интернетом, чтобы деревенский слесарь на своем телефоне узнал, что что-то не так и надо сходить посмотреть. Не сидеть же ему там круглые сутки. Отказал интернет. Это отказ? Нет. Потому что автоматика как работала так и работает, независимо от слесаря, пока всё в порядке. Ну зайдёт он лишний раз посмотрит, что там с интернетом и всё ли в порядке с насосом. Он и так обязан это делать.
Дальше - больше. Заменили 10 реле этим контроллером. Он всё равно есть - путь заодно управляет. Отказал интернет. Это отказ? Снова нет. Контроллер управляет, башня наполняется, всё работает, просто слесарь об этом не в курсе. Ничего не изменилось.
Повышаем градус. Заставим слесаря со своего телефона жать кнопки "вкл" и "откл" насосу, выкинем и релюхи и алгоритм из контроллера, сам контроллер попроще поставим. Отказал интернет. Это отказ? Уже да. Почему? Потому что на интернет возложена ответственная функция. А он априори ненадёжен, по определению.

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

Есть такое понятие - "ответственная функция". Везде оно разное по содержанию, но суть одинакова. И для ответственных функций любой интерфейс действительно, как правило, должен быть дублирован. И у Вас есть два пути на выбор чтобы решить эту задачу:
1. Дублировать интернет канал, и телефон слесаря, и самого слесаря, удвоив капитальные расходы и утроив эксплуатационные.
2. Сделать систему так, чтобы не было необходимости гонять ответственную функцию через интернет.

Техническое обоснование:
Рисуем структуру управления, расставляем ВБР, считаем общую надёжность.
Очевидно, что по п.1 ВБР будет куда как меньше чем по п.2.

Экономическое обоснование:
Стоимость решения складывается из трёх компонентов:
1. Стоимость разработки решения
2. Стоимость капитальных затрат (на реализацию решения)
3. Стоимость эксплуатационных затрат, что будет тратить пользователь: абонентка за интернет, зарплата слесарю + зарплата оператору (это хоть и в одном человеке, но работа-то двойная), обслуживание оборудования, амортизация оборудования.
Экономический эффект - разница стоимостей этих вариантов.
Лично Ваши затраты на оба пути - одинаковы, это Ваше время, потраченное на раздумья. А два других пункта будут разительно отличаться опять в пользу п.2, это очевидно.

Обоснование ремонтопригодности:
Контроллеры меняют раз в 5-10 лет и это выливается обычно в разработку по новой, потому что исходников обычно нет, да и контроллеры такие уже не купить. То есть стоимость разработки плюс кап.затраты повторяются. Плюс квалификация - слесарь в ПЛК не полезет, не его высота полёта. Программиста надо ждать из города. И он тоже будет копаться пару дней, чтобы сказать что контроллер надо менять (возвращаемся к капитальным затратам, внеплановым, плюс сроки на их исполнение). Всё это время деревня будет сидеть без воды.
А релюху поменяет и слесарь, в 30 проводах он тоже разберётся, и найти реле можно хоть по дворам на крайний случай, хотя в деревенской ТП наверняка они просто валяются. Справится за полдня. В деревне ничего не заметят, потому что в ёмкости есть запас, его хватит на это время.

Решение: управляем релюхами, а контроллером только мониторим. Разумный компромисс.

Вот так решаются такие задачи. Это два предпоследних пункта любого дипломного проекта - обоснование.

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

[+] И у меня такое было

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

Надёжный канал - это Ваш личный канал. А интернет - он не Ваш.

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

[Jackson]

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

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

Отправлено спустя 32 минуты 7 секунд:

Конечно Сименс надежнее и ломается раз в 1000 лет, а Контар раз в 100 лет - но их это почему то устраивало.

Действительно - почему?.... :)
Это как раз сарказм, если что.

[+] про надёжность

Вообще, у меня было интересное письмо от одного производителя электроники, который очень серьезно подошёл к вопросу оценки надёжности (не путать с отказоустойчивостью!) своих контроллеров. Учёт всех решений, всех операций, каждого резистора, каждой клеммы, статистика за 40 лет (и продолжает считаться)....
Суть в следующем: Рассчитываем срок службы оборудования = 10 лет. "Рассчитываем (могу ошибиться в терминах) наработку на отказ = 250 лет. Это значит, что за год имеет право сдохнуть одно изделие из 250 штук, либо за 250 лет точно сдохнут все. А что в реальности произойдёт в течение срока службы (10 лет) - как карта ляжет." По факту - в течение срока службы я за 25 лет не видел ни одного изделия, сдохшего просто так (то есть без внешних факторов). Сверх срока службы - да, бывает. Но не в пределах. Если в пределах - ищи внешний фактор, он обязательно есть. Есть от того производителя изделия мои ровесники одногодки, ещё работают.

Отправлено спустя 28 минут 27 секунд:

PS. ТЗ нет. Нужно писать.

Воооот! И эта тема про ТЗ тут на форуме очень часто повторяется.

Берёте ГОСТовский шаблон ТЗ на АСУ (он даже на форуме где-то есть в ВОРДе - я лично его делал и вставлял в него комментарии из ГОСТа) и просто внимательно заполняете каждый пункт. Это будет не три листочка, оно объёмное, потратите не полчаса, но зато:
1. Пока заполняете - сами поймёте о чём речь
2. Те, кому это ТЗ Вы сдадите, поймут его именно так, как Вы написали - шансов не будет понять что-то неправильно.

В ГОСТ есть как форма ТЗ, так и подробные пояснения, что именно надо описать буквально в каждом его пункте.

А иначе все те же самые усилия и время Вы всё равно потратите - выясняя и уточняя то, что не описали в ТЗ. Но только на этапе ТЗ Вы, может быть, переделаете само ТЗ, это как максимум бумага. А потом Вам придётся переделывать уже железо и софт, что куда как сложнее и дороже. Бумагу править проще чем хард и софт.

Как говорится: "Без ТЗ результат - х.з." (на эту тему много фольклора, даже песня есть).

[I_m]

Нет. Отказом является только то, что влияет на работу объекта.

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

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

А не ответственную можно? Да? Ну, хоть на этом спасибо. Нет? Ну, раздел фантастики этажом выше.

Надёжный канал - это Ваш личный канал.

Нет. Он ваш личный только по балансовой принадлежности. А в остальном его надёжность почти точно такая же, как и каналов провайдеров на последней миле, по крайней мере - всё те же самые факторы влияют.

[Jackson]

Да. Потому как в отсутствие связи мы не имеем актуальной и достоверной информации о состоянии объекта

Нет, потому что наличие или отсутствие такой информации у Вас не влияет на работу объекта. . Объекту фиолетово, знаете Вы про него или нет. Отказал интернет - это Ваша проблема, а не объекта, можно позвонить по телефону и спросить "у вас там всё нормально"?
На то и неответственная функция, что от её исполнения ничего не зависит.

[I_m]

Нет, потому что наличие или отсутствие такой информации не влияет на работу объекта

Да. Я нигде не говорил, что отказ связи означает отказ самого объекта. Кроме того, у самого объекта непосредственно есть масса отказов (хотя мне лично больше нравится калька с английского "аларм"), которые на его работоспособность не влияют никак или почти никак.
Если состояние связи с объектом относить к совокупности параметров состояния объекта, то её отказ - это аларм безусловно.

можно позвонить по телефону и спросить "у вас там всё нормально"?

Кому позвонить и у кого спросить? Наши железяки ИИ ещё не оснащены и разговаривать не умеют.

[olexsa]

Потому как в отсутствие связи мы не имеем актуальной и достоверной информации о состоянии объекта, в т.ч. работает ли он вообще.

Здесь много решающих факторов. В течении какого времени допускается отсутствие информации? Насколько критично отсутствие информации о состоянии объекта?
О том, что насосная работает, и вода поступает, можно судить и по косвенным параметрам. К примеру:
- если линия электроснабжения обособленная, и имеется доступ к её вводу, можно установить электросчетчик, или только трансформаторы тока, и судить о работе по значению потребляемого тока;
- на узле приема, то есть в конце линии установить расходомер, прибор измерения давления. Зафиксировать рабочие параметры, и по ним судить, идёт поступление или нет.

[+]

кстати, именно таким способом в бытность контролировали работу первого водоподъема. Находился он на расстоянии около 20 км от поселка. Периодически (раз в неделю) отправлялся персонал с осмотром здания, оборудования. Зимой, после метели, это была целая эпопея. О работе судили по давлению уже на входе на объект, потом допом поставили механический счетчик.
Автоматика простая: реле, ЭКМ, два насоса.
Проблем больше доставляло железо. Однажды сильно - сильно "прилипли" с этой темой, чуть котельную не разморозили. Так летом все службы капитально ревизировали всё: от элементарных вещей типа утепления окон и крыши, до замены задвижек, и ревизии насосов и двигателей с их ревизией.
Кстати, тоже продвигалась тема про автоматизацию, канал связи, и тому подобное. Посчитали - отказались. Выгоднее оказалось вложиться в ремонт и приведение в порядок имеющейся насосной станции.

[leon78]

Нет, потому что наличие или отсутствие такой информации не влияет на работу объекта. . Объекту фиолетово, знаете Вы про него или нет. Отказал интернет - это Ваша проблема, а не объекта, можно позвонить по телефону и спросить "у вас там всё нормально"?
На то и неответственная функция, что от её исполнения ничего не зависит.

Мы же не знаем, что там - просто диспетчеризация без управления, или "система диспетчерского контроля и УПРАВЛЕНИЯ".

[Ryzhij]

Кому позвонить и у кого спросить? Наши железяки ИИ ещё не оснащены и разговаривать не умеют.

Ух, ты! Вы превзошли уровень автоматизации, предсказанный Морли?
Но даже на предприятии будущего, согласно Ричарду Морли, будут два обитателя, один из которых - человек.
Впрочем, если Вам проще общаться со вторым обитателем, то звоните собаке.
А если серьёзно, то управленческие организационные проблемы техническими способами не решаются. Совсем.
И канал "связи пешими посыльными" является одним из самых надёжных.

[Jackson]

Да. Я нигде не говорил, что отказ связи означает отказ самого объекта.

Возвращаемся к вопросу: отказ ЧЕГО ?

Кому позвонить и у кого спросить?

На объект оператору. Вахтёру. Слесарю. Или съездить если там нет никого.

Здесь много решающих факторов.

И первый из них - постановка задачи. А в её отсутствии - вот и начинается холивар.

У автора даже ТЗ нет и описание объекта он не показал. О чём говорить? Я примеры привожу, дикое количество текста набиваю - только для того чтобы на конкретике это разобрать. Ведь вот тут задал эти вопросы, и они по прежнему актуальны, без них никак.

Мы же не знаем, что там - просто диспетчеризация без управления, или "система диспетчерского контроля и УПРАВЛЕНИЯ"

Мы даже не знаем, что это за место - "ТАМ". :)