Архитектура программного обеспечения для абстрагирования сенсорных интерфейсов - PullRequest
Новая
       23

Архитектура программного обеспечения для абстрагирования сенсорных интерфейсов

0 голосов
/ 16 марта 2020

Для проекта, над которым я работаю, я ищу Raspberry Pi, который запускает приложение, которое собирает данные с датчиков и отправляет эти данные на сервер apache Kafka для обработки. У меня есть инфраструктура больших данных и Apache Kafka, теперь я ищу предложения, чтобы я мог реализовать абстрактную часть программного обеспечения, которая может считывать любой датчик и протокол и отправлять эти данные в службу Kafka. Количество датчиков, тип и их протоколы не могут быть предварительно определены в программном обеспечении, оно должно быть полностью обобщено.

Поток будет следующим:

несколько датчиков (RPI ) -> программный интерфейс (RPI) -> программное обеспечение для структурирования данных с датчиков (RPI) -> отправка данных в службу Kafka для дальнейшей обработки.

Моя проблема сейчас заключается в том, что существует слишком много сенсорных протоколов для поддержки, и, честно говоря, поддерживая их, это добавляет большую сложность, которая, на мой взгляд, не является необходимой. Поэтому я ищу способ абстрагировать сенсорный API, который необходимо разработать. Методы, которые я рассмотрел до сих пор:

  1. gRP C: любой может написать свою собственную клиентскую заглушку на основе Protobuf и отправить данные на сервер без забот о протоколе или типе датчика (простейшая реализация, которую я смог найти).

  2. Архитектура сценариев : позволяя пользователям писать собственный сценарий датчика и отправлять данные в основное приложение, которое обрабатывает данные.

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

Учитывая, что система должна быть максимально простой в использовании для разработчиков и администраторов, я склоняюсь к методу gRP C. Но мой вопрос: есть ли более подходящие реализации для такой архитектуры, которые я мог бы пропустить?

1 Ответ

0 голосов
/ 18 марта 2020

Во-первых, мы, программисты, не являемся квалифицированными инженерами систем управления. Тебе лучше не участвовать ни в чем, способном повлиять на жизнь человека. Я должен сказать это, потому что некоторые строят системы, которые захватывают контроль над самолетом у пилота, а другие передают ИИ управление транспортными средствами, пока они проверяют свои телефоны. Эти плохие решения привели к гибели людей.

Стандарты ISA

https://www.isa.org/standards-and-publications/isa-standards/find-isa-standards-in-numerical-order/

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

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

http://www.powersemantics.com/e.html

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

...