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

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

Добрый день!

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

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

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

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

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

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

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

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

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


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

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

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

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

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

 

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

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

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

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

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


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

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 и Линукс - через специальный шлюз и область памяти.

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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 у, просто как графики(без ее оболочки) в мой десктоп...

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


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

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

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


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

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

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

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

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

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

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

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

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

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