Перейти к содержанию
    

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

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

Хотя еслиб масштаб цен позволял - покупал бы.

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

К примеру если цикл ПЛК 0.5 секунды то нафига успевать среагировать и обрабатывать евент за микросекунды?

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

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

Но будут ли валидные данные в памяти в это время?

ПЛК не гарантирует никаким образом программе выполнение за цикл.

 

А гарантирует профайлинг и модели планирования.

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

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

 

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

 

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

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

Определились бы уже. :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Но будут ли валидные данные в памяти в это время?

ПЛК не гарантирует никаким образом программе выполнение за цикл.

 

А гарантирует профайлинг и модели планирования.

В ПЛК планирование на рудиментарном уровне, в виде нескольких параллельных задач с жестко заданными приоритетами.

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

 

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

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Определились бы уже. :laughing:

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Говорите уже своими словами.

Вотчдог - это авария.

Рушится обмен на всех шинах. Все слэйвы уходят в ступор, появляется непредсказуемая пауза, теряются состояния процессов, прерываются записи на носители и т.д. и т.п.

У вас же такая навороченная программа, работает по всем мыслимым интерфейсам.

И представьте, вам спец приходит и заявляет - у нас жесткий риалтайм, но если что, то все может рухнуть, зато надежно.

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Рушится обмен на всех шинах. Все слэйвы уходят в ступор, появляется непредсказуемая пауза, теряются состояния процессов, прерываются записи на носители и т.д. и т.п.

У вас же такая навороченная программа, работает по всем мыслимым интерфейсам.

И представьте, вам спец приходит и заявляет - у нас жесткий риалтайм, но если что, то все может рухнуть, зато надежно.

 

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

И если да, то на основании чего, мне очень интересно? :biggrin:

А если нет - то в чем тогда их преимущество ?

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Рушится обмен на всех шинах. Все слэйвы уходят в ступор, появляется непредсказуемая пауза, теряются состояния процессов, прерываются записи на носители и т.д. и т.п.

У вас же такая навороченная программа, работает по всем мыслимым интерфейсам.

И представьте, вам спец приходит и заявляет - у нас жесткий риалтайм, но если что, то все может рухнуть, зато надежно.

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

до последнего бита и проводка.

1. Читаем errata на ВСЕ что используется из комплекующих, и пытаемся ЭТО предусмотреть в коде.

2. Читаем errata, и "мечтаем", что там моежт появиться в следующей ревизии (но глючек уже в этой).

3. Неоткрытая элементарная частица из Вселенной влетает в ГЛАВНЫЙ РЕГИСТР системы и все рушится.

(одна надежда, что по вероятности ОНО не затронет WD).

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...