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

Есть ли какое-то неведомое ограничение на Python в надёжных системах

Добрый день, коллеги! Извините за пафосный заголовок, но другого придумать не смог)

 

Ситуация такая: есть промышленный компьютер в щите, к которому через шину RS-485 подключены некие модули ввода-вывода. С одних модулей мы читаем ифнормацию, принимаем решение и скармливаем это решение модулям вывода. Скорость шины 115200, длина управляющих пакетов не более 64 байт. Модулей около 16 штук. 

 

Допустимо ли использовать интерпретатор Питона, запущенный как фоновый процессс в Линуксе? Самое главное, что некая задержка в обмене данными, вызыванная Линуксом или самим интерпретатором - некритична. Даже, если это будет 500 - 1500 мс. Но важно, чтобы сам по себе процесс не завершился спонтанно. Это очень нежелательно. В принципе тест показывает, что всё успешно работает уже неделю в режиме 24/7.

 

Мой вопрос: есть ли какие-то подводные камни, о которых я могу не знать? Я не являюсь большим знатоком Линукса и Питона. Моё решение временное до завершения проекта по "нормальному" компу с ОСРВ. Может быть, что, например, Линукс "неожиданно" завершит процесс по каким-то причинам? Или сам интерпретатор Питона свалится через 12 дней, например, из-за известного бага переполнения какого-либо счётчика?

 

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

 

З.Ы. Если есть хорошие статейки на данную тему, то можно сразу направить на них.

З.Ы.Ы. Linux 2020.08.2.

               Железо на базе МК AT91SAM9G45.

               Python 3.7.1

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


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

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

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


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

4 hours ago, MrBearManul said:

важно, чтобы сам по себе процесс не завершился спонтанно.

Первое же неперехваченное исключение в Питоне и он как раз и 'завершится спонтанно'. Всё зависит от скрипта, который крутится на интерпретаторе

 

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


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

6 часов назад, rkit сказал:

чтобы она спокойно переживала падения и перезапускалась.

Согласен с вашим замечанием. Внешний WDT прикрутить небольшая проблема на платке.

3 часа назад, xvr сказал:

Всё зависит от скрипта, который крутится на интерпретаторе

В общем там ввод-вывод через USB CDC (на преобразователь в шину RS-484), несложная математика, опрос часов реального времени, т.к. управление привязано к календарю. Но в целом можно следовать совету уважаемого @rkit.

 

Спасибо, коллеги!

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


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

26.02.2021 в 10:49, MrBearManul сказал:

Мой вопрос: есть ли какие-то подводные камни, о которых я могу не знать?

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

16 часов назад, MrBearManul сказал:

В общем там ввод-вывод через USB CDC (на преобразователь в шину RS-484), несложная математика, опрос часов реального времени, т.к. управление привязано к календарю.

Тогда вопрос - что в такой архисложной задаче нельзя было сделать на "чистом" Си?

22 часа назад, rkit сказал:

чтобы она спокойно переживала падения и перезапускалась.

Честно говоря, это не гуд для ответственных систем, такой подход еще можно использовать для како-го нить планшетика, для игрушек...

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

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


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

57 minutes ago, mantech said:

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

У вас судя по всему слишком узкий опыт, поэтому мнение не очень компетентное. 
Надежные системы строяться на целом стеке  "прослоек".
Например для индустриального оборудования мы создаем алгоритм в Matlab, там мы используем Stateflow в графической нотации, из него генерим автоматически сорсы на ST, код на ST грузим в среду разработки PLC, среда разработки PLC превращает это в некий протокод, этот протокод  уже в PLC превращается в машинный код. 
Ни на одном этапе сам код никто не смотрит на "прозрачность".
Здесь проблема не в прослойках, а в правильном их стеке.   

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


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

2 минуты назад, AlexandrY сказал:

Надежные системы строяться на целом стеке  "прослоек".

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

4 минуты назад, AlexandrY сказал:

генерим автоматически сорсы на ST, код на ST грузим в среду разработки PLC, среда разработки PLC

И что, "прозрачный" код на Си тоже потом попадает в компилятор...

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


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

13 minutes ago, mantech said:

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

А с этим согласен.
Но опять же вспомним опыт с языком C.
Когда в промышленное программирование ломанулось нерды со своими заумными лексемами, которые не может распарсить даже компилятор, то против них придумали MISRA.  
Так и с пионом, если ограничить лексикон и ассортимент подключаемых либ, то вполне можно сделать надежные решения даже в ненадежной вобщем-то среде.  
Просто в питоне это придется искать собственной головой об стенку. Но так малобюджетные проекты и делаются. Вкладываются не в средства разработки, а в выжимание разработчиков. 

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


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

3 часа назад, AlexandrY сказал:

Так и с пионом, если ограничить лексикон и ассортимент подключаемых либ, то вполне можно сделать надежные решения даже в ненадежной вобщем-то среде.

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

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

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


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

Коллеги, все ответы прочитал. Выводы сделал. Система временная, внешний вочдог пока как костылик... Спасибо)

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


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

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...