Jump to content

    
Sign in to follow this  
MrBearManul

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

Recommended Posts

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

 

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

 

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

 

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

 

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

 

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

З.Ы.Ы. Linux 2020.08.2.

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

               Python 3.7.1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
4 hours ago, MrBearManul said:

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

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

 

Share this post


Link to post
Share on other sites
6 часов назад, rkit сказал:

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
26.02.2021 в 10:49, MrBearManul сказал:

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

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

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

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

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

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

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

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

Edited by mantech

Share this post


Link to post
Share on other sites
57 minutes ago, mantech said:

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

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

Share this post


Link to post
Share on other sites
2 минуты назад, AlexandrY сказал:

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

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

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

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

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

Share this post


Link to post
Share on other sites
13 minutes ago, mantech said:

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

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

Share this post


Link to post
Share on other sites
3 часа назад, AlexandrY сказал:

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this