Лучшая структура или системная архитектура для проектирования и программирования систем телеметрии / SCADA [закрыто]

Question

Я спросил вопрос о хорошей книге по этой теме.

На него не так много ответов, так что, возможно, хороших книг нет (хотя мне это кажется странным;Мне нужно самому пойти поискать на Amazon).

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

Как я спросил в другом вопросе:

Я рассматриваю несколько проектов, все с примерно одинаковым функционалом.

Некоторые инструменты собирают некоторые данные (или управлять некоторой функциональностью).Они общаться через Интернет (Ethernet/Wi-Fi/GPRS/спутник) с сервер базы данных, на котором хранится измерения и предоставляет браузер основанные на средствах запроса данных, составление отчетов и т.д. (и, возможно, также позволяет управлять пультом дистанционного управления оборудования).

Может ли кто-нибудь порекомендовать хорошую книгу Описание подхода к разработке такую архитектуру программного обеспечения, сохраняя Это обобщенные, какие инструменты, языки.методы тестирования и т. д. использовать?

Вместо «книги» замените «фреймворк, несколько хороших URL-адресов или просто общие советы».

Это очень распространенная системная закономерность.Кто может посоветовать?

Answer 1

Я написал полную систему SCADA (за исключением специального инструментального оборудования).Система была разработана как универсальная, позволяющая создавать новые модели оборудования, инструменты и сбор данных. Она не была написана как многие системы SCADA для отдельной компании/завода, но используется по всему миру тысячами компаний/заводов.

Я был единственным разработчиком/дизайнером, а один из руководителей курировал и руководил проектом.Этот путь занял больше времени, но это было выполнимо.Мы рассмотрели другие уже имеющиеся системы/платформы SCADA и решили, что, поскольку наши устройства были изготовлены по индивидуальному заказу, было бы проще и гибче написать систему с нуля, используя существующие среды разработки и сторонние компоненты.Оглядываясь назад, можно сказать, что для нас это сработало очень хорошо, потому что у нас было время и навыки, но, как правило, это не лучшее решение в зависимости от вашей модели бизнеса/контракта.

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

Архитектура системы

Вот общий обзор того, из чего состояла система:

• Пользовательские сотовые устройства с универсальными входами для работы с несколькими инструментами разных типов. (аналоговый, цифровой, давление, сила тока, поплавок и т. д.)
• Пакеты UDP/TCP пользовательского формата отправлялись устройствами через сотовую сеть (GPRS) на наши серверы (Windows-сервер 2003 Р2).Информация отправлялась регулярно для отчетности, а также о настраиваемых изменениях состояния, которые можно было запрограммировать на устройстве или в Интернете. (конфигурация, отправленная по сотовой сети).
• Пользовательский многопоточный .СЕТЬ приложение, использующее прослушиватели TCP/UDP, которые захватывают входящие пакеты (несколько сотен тысяч в день), расшифровал пользовательские заголовки и направил пакеты без дальнейшей интерпретации в правильную базу данных. (Некоторым клиентам требовалась собственная автономная система)
• А Майкрософт SQL 2005 база данных, которая выступала в качестве мозга для всей системы.Пакеты интерпретировались с использованием CLR-функции и автоматически активируемые сигналы тревоги (как настроено), составлял отчеты и вел полную историю
• Обычай .СЕТЬ приложение для обработки оповещений путем совершения телефонных звонков, отправки SMS-сообщений и отправки электронных писем.Логика телефона обрабатывалась Карта Intel Dialogic по аналоговым линиям, используя комбинацию записанных подсказок и преобразования текста в речь.
• 3 АСП.НЕТ места:
  • Сайт, ориентированный на клиентов, который позволял им управлять своими учетными записями/подпользователями, отслеживать оповещения, настраивать устройства и оповещения, данные диаграмм, картографические устройства, экспортировать отчеты и т. д.
  • Сайт продаж, который позволял распространять материалы среди продавцов, отслеживать отдельные устройства, составлять отчеты о состоянии устройств и т. д.
  • Сайт внутреннего управления, который позволял создавать учетные записи клиентов, настраивать/создавать подразделения и использовать все другие административные функции по мере необходимости.
• Также существовала специальная внутренняя система мониторинга для проверки работоспособности системы и оповещения технических специалистов о проблемах при необходимости, поскольку системе требовалась круглосуточная работоспособность.
• Кроме того, мы создали iOS-приложение, а мобильный сайт, и пользовательский веб-сервис/клиент (API), чтобы позволить клиентам получать данные о клиентах напрямую, чтобы они могли интегрировать наше решение с существующими (обычно индивидуально) СКАДА-системы.

Это компоненты, которые мы использовали, и они работали.Делая это снова, я бы изменил пару вещей.я хотел бы использовать Windows Сервер 2008 Р2, SQL 2008 Р2, а вместо карты Dialogic я бы использовал Microsoft Скажи мне с помощью VoIP.Я бы также использовал Сильверлайт вместо ASP.NET.Мне очень нравится ASP.NET, но Silverlight может дать гораздо лучшее представление и при необходимости может использоваться вне браузера — частый запрос операторов SCADA.

Все используемые сайты Сторонние компоненты чтобы диаграммы и таблицы не приходилось писать с нуля.Есть некоторые специфические компоненты SCADA. (в основном на основе Java) там.Однако мы обнаружили, что большинство из них грубы, уродливы или слишком специфичны для использования в нашей общей системе. (тоже дорого!Было проще и гибче настроить пакет датчиков/графиков, чтобы «сделать» свой собственный).

Как уже упоминалось, мозгом системы была база данных.Это было сделано потому, что Microsoft SQL — это отличный продукт с хорошей поддержкой, рассчитанный на максимальное время безотказной работы и обладающий отличными возможностями резервного копирования и повышения производительности.Мы также были очень впечатлены Интеграция .NET CLR это было возможно, позволяя запускать наш собственный код .NET как часть этого процесса.Устройства, которые мы поддерживали, выпускались в различных моделях и могли быть настроены для использования любой комбинации инструментов, поэтому сохранение гибкости базы данных было ключевым моментом. Мы использовали много нормализации!

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

В прошлом мы имели дело с OPC, но сочли его слишком негибким, сложным и раздражающим для наших нужд.Хотя это было несколько лет назад, и с тех пор я на него не смотрел.

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