Real-time и не-real-time - в одном флаконе или раздельно? Опции

[mantech]

Вы мне льстите (шедеврально). В моем посте слово "заплатить" не фигурировало.
Хотя еслиб масштаб цен позволял - покупал бы.

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

В нормально спроектированной RTOS зависание не возможно

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

[syoma]

В любом нормально спроектированном софте не возможно, и это факт!

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

[AlexandrY]

Понятие "реальное время" перпендикулярно тому, через сколько времени ртось среагирует на событие.
Если ртось УСПЕВАЕТ ВОВРЕМЯ среагировать и обработать евент за ДЕТЕРМИНИРОВАННОЕ время и это время устраивает заказчика, значит это ртось. Даже если время реакции сотни милисекунд
К примеру если цикл ПЛК 0.5 секунды то нафига успевать среагировать и обрабатывать евент за микросекунды?

Тогда убойный вопрос: откуда вы знаете что ваша программа в ПЛК реагирует за детерминированное время?
В ПЛК есть только цикл и все. Вы только знаете что он выполняется за скажем 2 мс и всегда обновит выходы данными из памяти за это время.
Но будут ли валидные данные в памяти в это время?
ПЛК не гарантирует никаким образом программе выполнение за цикл.

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

Реальное время в современной трактовке - инструмент, а не явление. RTOS - это фреймворк, а не просто планировщик и объекты синхронизации.

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

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

[mantech]

Тогда убойный вопрос: откуда вы знаете что ваша программа в ПЛК реагирует за детерминированное время?
В ПЛК есть только цикл и все. Вы только знаете что он выполняется за скажем 2 мс и всегда обновит выходы данными из памяти за это время.
Но будут ли валидные данные в памяти в это время?
ПЛК не гарантирует никаким образом программе выполнение за цикл.

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

Если сказано, что время реакции на событие должно быть 5 мсек, значит цикл ПЛК, должен быть как минимум в 2 раза быстрее, тогда все данные будут валидными. По моему все понятно

Сообщение отредактировал mantech - Oct 29 2017, 12:25

[AlexandrY]

Если сказано, что время реакции на событие должно быть 5 мсек, значит цикл ПЛК, должен быть как минимум в 2 раза быстрее, тогда все данные будут валидными. По моему все понятно

Не видно оснований для такой эвристики.

[mantech]

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

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

[syoma]

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

Что значит "готов порвать"? Задача ватчдога как раз в том, чтобы гарантировать реальное время. Т.е. если у меня цикл 5мс, то программа должна выполниться за меньшее время. Как мы можем это гарантировать? Легко - ставим ватчдог, который будет срабатывать, если время выполнения программы превысит 5мс. Данный ватчдог будет возвращать систему в безопасное состояние - в моем случае это отключение всех выходов и ресет микроконтроллера.

В итоге что мы имеем? Либо гарантированное реальное время ЛИБО безопасное состояние. Все, других вариантов нет.

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

Тогда убойный вопрос: откуда вы знаете что ваша программа в ПЛК реагирует за детерминированное время?

Данный ответ работает и для ПЛК. Если в вашем ПЛК не срабатывает ватчдог и он не вываливается в безопасное состояние, значит его программа выполняется за детерминированное время.

[AlexandrY]

Что значит "готов порвать"? Задача ватчдога как раз в том, чтобы гарантировать реальное время.

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

В ПЛК не вотчдог, а набор штатных сигналов о нарушениях на шинах связи и проч. проверки. О реальном вотчдоге там нигде ни слова!

[mantech]

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

Вы можете гарантировать на 100% безотказность ваших программ в неблагоприятных условиях и в режиме 24\7 ?
И если да, то на основании чего, мне очень интересно?
А если нет - то в чем тогда их преимущество ?

Сообщение отредактировал mantech - Oct 30 2017, 07:25

[gosha-z]

Вы можете гарантировать на 100% безотказность ваших программ в неблагоприятных условиях и в режиме 24\7 ?

Безотказность - нет, уменьшить вероятность возникновения аварийных ситуаций - да. Ключевое слово - Functional safety.

[mantech]

Безотказность - нет, уменьшить вероятность возникновения аварийных ситуаций - да. Ключевое слово - Functional safety.

Правильно, и в любом случае без ватчдога не обойтись.

[gosha-z]

Правильно, и в любом случае без ватчдога не обойтись.

Весь вопрос в том - что рвать WDog'ом. Поэтому и исповедуется мысль отделять mission-critical части от user interface

[syoma]

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

И? Реальное время надо уважать. Иначе это будет очередная IoT поделка, коих сегодня развелось очень много.

В ПЛК не вотчдог, а набор штатных сигналов о нарушениях на шинах связи и проч. проверки. О реальном вотчдоге там нигде ни слова!

Можете почитаете доки? Во всех ПЛК, что я видел, есть Watchdog, как программные - следящие за выполнением отдельных задач, так и аппаратные.

[AlexandrY]

Можете почитаете доки? Во всех ПЛК, что я видел, есть Watchdog, как программные - следящие за выполнением отдельных задач, так и аппаратные.

Эт вы уже стали играть терминами. Я в такие игры не играю.

[k155la3]

>> В любом нормально спроектированном софте не возможно, и это факт!

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

Можно было бы попытаться дать гарантию безошибочности (100 %, или хотябы 9.999 ), если бы весь "продукт" был свой, доморощенный.
до последнего бита и проводка.
1. Читаем errata на ВСЕ что используется из комплекующих, и пытаемся ЭТО предусмотреть в коде.
2. Читаем errata, и "мечтаем", что там моежт появиться в следующей ревизии (но глючек уже в этой).
3. Неоткрытая элементарная частица из Вселенной влетает в ГЛАВНЫЙ РЕГИСТР системы и все рушится.
(одна надежда, что по вероятности ОНО не затронет WD).