Особенности проектирования системы OPC в реальном времени - PullRequest
Новая
       28

Особенности проектирования системы OPC в реальном времени

1 голос
/ 12 апреля 2011

Мы находимся в процессе перестройки разрозненной системы OPC в реальном времени, которая оказалась громоздкой. Наш технологический стек - C #, .NET 4 и SQL Server 2008 R2, размещенный на 32-разрядной Windows Server 2003. Физическая архитектура в настоящее время требует, чтобы все уровни были размещены на одном сервере, хотя с достаточной мотивацией (читай: ROI) это может быть увеличено до 2.

Базовая существующая архитектура:

  • Внешние устройства OPC обращаются в наш веб-сервис для заполнения SQL данными в реальном времени, примерно 300 событиями в секунду. У нас нет никакого контроля над объемом или пакетной обработкой здесь, хотя в переписывании я хотел бы реализовать пакетную обработку в веб-сервисе, чтобы сэкономить SQL от 300 операторов вставки в секунду.
  • SQL используется в качестве центрального ресурса для различных компонентов (всего около 9, которые должны быть переработаны), которые выполняют задачи, начиная от аварийных сигналов и заканчивая отчетами. В настоящее время это самая большая проблема в существующем проекте, так как нет ни одного BLL или даже DAL, через который все эти компоненты используют / манипулируют данными или управляют поведением.
  • Компоненты варьируются от служб Windows до веб-служб и приложений Windows. Крупнейшим потребителем процессорного времени и SQL-соединений является приложение Windows Forms, которое отслеживает все данные в реальном времени и выдает аварийные сигналы по мере необходимости. Он также создает графики трендов в реальном времени, которые довольно дороги для запуска.

Для переписывания есть сильный толчок к WPF, с которым, кроме кривой обучения, у меня нет проблем. Мой вопрос больше касается базовой архитектуры:

  • В настоящее время я занимаюсь изучением того, как реализовать один DAL и BLL. Что касается DAL, я склоняюсь к EF или nHibernate, также возможен Linq-to-SQL.
  • Что касается BLL, у меня есть опыт работы только с CSLA.NET, и я боюсь, что это может быть слишком много для системы, в которой скорость и потребление ресурсов имеют решающее значение.

Кто-нибудь имеет опыт работы с подобной системой и готов поделиться несколькими уроками или рекомендациями по дизайну?

Ответы [ 2 ]

1 голос
/ 12 апреля 2011

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

1) Для сбора данных в режиме реального времени вам понадобится что-то на основе механизма публикации и подписки, BizTalk Server - это ответ Microsoft на ESB.Итак, я бы посмотрел на это.
2) Нужно ли приложению Windows Forms напрямую обращаться к базе данных?Я имею в виду, может ли он взглянуть на промежуточное звено, которое может сказать, посмотреть на БД для исторических целей или подписаться на канал в реальном времени, если все, что его волнует, это информация в реальном времени

0 голосов
/ 12 апреля 2011

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

Протокол OPC включает клиентов, подписывающихся на сервер, поэтому они могут быть уведомлены об изменении любых данных. Использование SQL в середине предотвращает это.

Не лучше ли вам использовать / создать сервер OPC для извлечения всех данных с устройства, а затем разрешить каждому клиенту подключаться к этому? Таким образом, они получают данные только при их изменении, вместо того, чтобы постоянно проверять наличие обновлений?

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

...