Jump to content

    

Выбор стека проектирования для пром. системы под Linux, серверной и мобильной части

Recommended Posts

Quantum1

Добрый день!

Опишу задачу.

Сейчас разрабатываю некую промышленно/научную систему, которая управляется с многоядерного SoC, часть ядер работает только на саму реал-тайм систему, а на другой части должен крутиться Линух, на котором стоят апы для визуализации процесса (всякие графики и т.д.), HMI, и иной софт для пользователя. Также это система в перспективе должна общаться с неким удаленным сервером/операторской (которая может быть в принципе на другом континенте), на предмет архивирования данных и управления процессом. Также желательно подцепить мониторинг со смартфона/планшета, через этот самый удаленный сервер.

Я специализируюсь на разработке железа, и основные мои скилы по софту лежат в хард)) Т.е. C/C++, ASM ну итд...

Когда то лет 12 - 15 назад писал что то для веба - PHP, HTML, Java, JavaScript... Чуток касался Mysql, C#….

В чем собственно вопрос? Мне нужно определиться со тех. стеком, на котором необходимо реализовать так сказать софтовый софт), который описан в первом абзаце, т.е. приложения под Линух, общение с удаленным сервером, приложения под смартфон.

Сначала был только Windows, и я начал творить в Visual Studio. Сейчас потребовался Линух и необходимость в будущем работать удаленно и т.д.

В “софтовом” софте я не большой спец, и даже по Линух ничего раньше не писал. Подскажите пожалуйста что выбрать для реализации указанных задач, возможно ли все реализовать на какой-нибудь единой платформе (наборе фреймворков итд...), с минимальным количеством разных языков?

П.С. готовую SCADA использовать не могу/не хочу, так как пром. система крайне специфична много мелких реалтаймовых точных процессов где и ни одна SCADA с ними не справиться должным уровнем. Тем более мне совершенно не нужен один из основных девизов SCADA - “даже девочка, без знания программирования может работа”, а также я не использую ни один сторонний пром. контроллер или модуль - они не справятся.

Share this post


Link to post
Share on other sites

_pv

просто как пример того, что нынче на C/C++ написанное можно скомпилировать в "браузер", а там уже без разницы виндовс/линукс/андроид/иОс/...

https://schteppe.github.io/imgui-wasm/

https://github.com/ggerganov/imgui-ws

по сути (с точки зрения количества вложенных обёрток) ужос конечно, но вот оно - кроссплатформенное будущее, которое мы заслужили.

 

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

реалтайм часть прям совсем отдельный baremetal? 

как объяснить ОС что вот эти ядра/память/io/прерывания отрезаны под реалтайм и "ты туда не ходи", 

через что реалтайм/нереалтайм между собой коммуницируют 

Share this post


Link to post
Share on other sites

Quantum1
8 hours ago, _pv said:

просто как пример того, что нынче на C/C++ написанное можно скомпилировать в "браузер", а там уже без разницы виндовс/линукс/андроид/иОс/...

https://schteppe.github.io/imgui-wasm/

https://github.com/ggerganov/imgui-ws

по сути (с точки зрения количества вложенных обёрток) ужос конечно, но вот оно - кроссплатформенное будущее, которое мы заслужили.

 

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

реалтайм часть прям совсем отдельный baremetal? 

как объяснить ОС что вот эти ядра/память/io/прерывания отрезаны под реалтайм и "ты туда не ходи", 

через что реалтайм/нереалтайм между собой коммуницируют 

Да, все верно все что управляет железом системы -датчики, клапаны, движки ну итд. Там жёсткий реалтайм, на чистом baremetal, со своими функциями критических защит, резервированием, контролем сбоев и лажи от пользователя и тд 

У некоторых ядер есть свои индивидуальные кешы, а на весь SoC есть контроллер общих кешев,периферии и памяти, в котором можно настроить уровни доступа, к примеру ядро с самым высоким может ходить где вздумается и влезать куда хочет, ядро с низким уровнем не сможет залезть в закрытую для нее периферию или область памяти. Таким образом ответственные процессы выполняются на высоко приоритетных ядрах в baremetal, а пользовательские приложухи и Линукс крутятся на сильно ограниченных, шоб ничего не сломали) общение между baremetal и Линукс - через специальный шлюз и область памяти.

Edited by Quantum1

Share this post


Link to post
Share on other sites

Quantum1

Еще поизучал вопрос, вероятно самое правильное решение сделать фронтендовую графически-пользовательскую-интерфейсную часть на все том же html/js/css итд...

а бекэнд, пока не знаю, мини-сервер что ли поднимать...

Share this post


Link to post
Share on other sites

syoma

Мы такое делали - сама система управления на реалтайме DSP + FPGA, и к ней сервер доступа. 

Сначала следует определиться с требованиями - то есть описать типичные сценарии "Я, как оператор, хочу сделать то-то и то-то через это", "Я, как разработчик системы, хотел бы иметь доступ к таким-то и таким-то данным в таком-то виде" и т.д.

Тогда повылазят интересные кейсы, наиболее часто требующие:

- либо простого лога событий с тайм-стампингом(то есть каждый эвент должен логгироваться с абсолютной точностью до 10микросекунд (PTP)) с возможностью иерархической фильтрации по любому эвенту и временным интервалам.

- либо аналога Transient Fault Recorder - то есть непрерывной записи какого либо сигнала в течении ограниченного времени (например пара десятков секнуд по триггеру с пре- и пост-триггером) с последующей возможностью отображения в графическом виде, многоканальной записью и высокой разрешающей способностью по времени (в идеале равной частоте опроса датчиков и работы реалтаймовой системы) и естественно с тоже четкой привязкой к тайм-стампу.

По итогу все это вылилось в такую себе сборную солянку:

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

- доступ к базе и соответственно ко всем сигналам через REST API интерфейс, возвращается JSON объект.

- При записи нового значения в какой либо сигнал (например, изменить установку) нужно тоже просто отправить REST API запрос.

- Отдельно от системы ставится сервер доступа - индустриальный PC на линуксе, задача которого опрашивать одну или несколько систем (их у нас может быть до 10) и сохранять все полученные базы у себя, с многократными энергонезависимыми бекапами. Там же крутится HTTP сервер визуализации и представления данных.

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

В общем вся разработка была сосредоточена в сервере доступа - использовалась куча разных фреймворков - Kafka, Graphana - это некоторые, которые я запомнил, но все в принципе довольно неплохо работало.

Share this post


Link to post
Share on other sites

Quantum1
13 hours ago, syoma said:

Мы такое делали - сама система управления на реалтайме DSP + FPGA, и к ней сервер доступа. 

Сначала следует определиться с требованиями - то есть описать типичные сценарии "Я, как оператор, хочу сделать то-то и то-то через это", "Я, как разработчик системы, хотел бы иметь доступ к таким-то и таким-то данным в таком-то виде" и т.д.

Тогда повылазят интересные кейсы, наиболее часто требующие:

- либо простого лога событий с тайм-стампингом(то есть каждый эвент должен логгироваться с абсолютной точностью до 10микросекунд (PTP)) с возможностью иерархической фильтрации по любому эвенту и временным интервалам.

- либо аналога Transient Fault Recorder - то есть непрерывной записи какого либо сигнала в течении ограниченного времени (например пара десятков секнуд по триггеру с пре- и пост-триггером) с последующей возможностью отображения в графическом виде, многоканальной записью и высокой разрешающей способностью по времени (в идеале равной частоте опроса датчиков и работы реалтаймовой системы) и естественно с тоже четкой привязкой к тайм-стампу.

По итогу все это вылилось в такую себе сборную солянку:

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

- доступ к базе и соответственно ко всем сигналам через REST API интерфейс, возвращается JSON объект.

- При записи нового значения в какой либо сигнал (например, изменить установку) нужно тоже просто отправить REST API запрос.

- Отдельно от системы ставится сервер доступа - индустриальный PC на линуксе, задача которого опрашивать одну или несколько систем (их у нас может быть до 10) и сохранять все полученные базы у себя, с многократными энергонезависимыми бекапами. Там же крутится HTTP сервер визуализации и представления данных.

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

В общем вся разработка была сосредоточена в сервере доступа - использовалась куча разных фреймворков - Kafka, Graphana - это некоторые, которые я запомнил, но все в принципе довольно неплохо работало.

Большое спасибо за развернутый ответ!!

Постепенно изучаю тему, что да вероятно путь похожий на тот что вы описали мне нужно пройти.

Т.е.

1) одна программа в Линухе получает данные из шлюза от реал-тайм части, и передает их во time series БД, пока приглянулась Prometheus.

2) БД их запоминает.

3) Выводит или на свои дашборды, или на сторонние - да как раз наверное Graphana.

4) Необходимо эти дашборды встроить в общий пользовательский интерфейс управления. Общий интерфейс управления должен внешне выглядеть, как десктопное приложение (а под капотом там web  допустим Electron или  NW.js и т.д.), что бы пользователь никуда залезть без разрешения не мог.

Такая операция планируется пока изолированно на машине - т.е. и БД, и шлюз общения с Real-time частью и дашборды, и десктоп. Все это работает в одном Линухе и на одной машине.

Мне тут пока не очень понятно несколько вещей. Как ручками подсовывать данные в БД, стандартные сборщики данных тут не подойдут.

Как встроить Graphan у, просто как графики(без ее оболочки) в мой десктоп...

Share this post


Link to post
Share on other sites

gosha
On 4/10/2022 at 9:05 PM, Quantum1 said:

Добрый день!

Опишу задачу.

Сейчас разрабатываю некую промышленно/научную систему, которая управляется с многоядерного SoC, часть ядер работает только на саму реал-тайм систему, а на другой части должен крутиться Линух, на котором стоят апы для визуализации процесса (всякие графики и т.д.), HMI, и иной софт для пользователя. Также это система в перспективе должна общаться с неким удаленным сервером/операторской (которая может быть в принципе на другом континенте), на предмет архивирования данных и управления процессом. Также желательно подцепить мониторинг со смартфона/планшета, через этот самый удаленный сервер.

Я специализируюсь на разработке железа, и основные мои скилы по софту лежат в хард)) Т.е. C/C++, ASM ну итд...

Когда то лет 12 - 15 назад писал что то для веба - PHP, HTML, Java, JavaScript... Чуток касался Mysql, C#….

В чем собственно вопрос? Мне нужно определиться со тех. стеком, на котором необходимо реализовать так сказать софтовый софт), который описан в первом абзаце, т.е. приложения под Линух, общение с удаленным сервером, приложения под смартфон.

Сначала был только Windows, и я начал творить в Visual Studio. Сейчас потребовался Линух и необходимость в будущем работать удаленно и т.д.

В “софтовом” софте я не большой спец, и даже по Линух ничего раньше не писал. Подскажите пожалуйста что выбрать для реализации указанных задач, возможно ли все реализовать на какой-нибудь единой платформе (наборе фреймворков итд...), с минимальным количеством разных языков?

П.С. готовую SCADA использовать не могу/не хочу, так как пром. система крайне специфична много мелких реалтаймовых точных процессов где и ни одна SCADA с ними не справиться должным уровнем. Тем более мне совершенно не нужен один из основных девизов SCADA - “даже девочка, без знания программирования может работа”, а также я не использую ни один сторонний пром. контроллер или модуль - они не справятся.

большинство на QT пишет приложения, включающие socket и GUI: https://doc.qt.io/qt-5/qtcpsocket.html

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.