Mejor marco o arquitectura de sistema para diseño y programación de sistemas de telemetría/SCADA [cerrado]

Question

Yo pregunté una pregunta sobre un buen libro para este tema.

No recibe muchas respuestas, así que tal vez no haya ningún buen libro (aunque me parece extraño;Debo ir a buscar en Amazon por mí mismo).

A falta de un libro, tal vez haya un buen marco, algunas buenas URL o simplemente consejos generales.

Como pregunté en la otra pregunta:

Estoy mirando varios proyectos, todos con aproximadamente la misma funcionalidad.

Algunos instrumentos recopilan algunos datos (o controlan alguna funcionalidad).Se comunican por Internet (Ethernet/Wifi/GPRS/Satellite) con un servidor de base de datos que almacena las medidas y proporciona un medio basado en el navegador para consultar los datos, producir informes, etc. (y posiblemente también permite el control del equipo remoto).

¿Alguien puede recomendar un buen libro que describa un enfoque para desarrollar una arquitectura de software de este tipo, mantenerlo genérico, qué herramientas, idiomas?¿Métodos de prueba, etc. a utilizar?

En lugar de "libro", sustituya "marco, algunas buenas URL o simplemente consejos generales".

Este es un patrón de sistema muy común.¿Quién puede aconsejar?

Answer 1

He escrito un sistema SCADA completo. (excluyendo el hardware de instrumentación personalizado).El sistema fue diseñado para ser genérico y permitir la creación de nuevos modelos de hardware, instrumentos y recopilación de datos; no fue escrito como muchos sistemas SCADA para una empresa/planta individual, sino que es utilizado internacionalmente para miles de empresas/plantas.

Yo era el único desarrollador/diseñador y un miembro de la dirección supervisaba y guiaba el proyecto.De esa manera tomó más tiempo, pero fue factible.Analizamos otros sistemas/marcos específicos de SCADA que ya existen y decidimos que, dado que nuestras unidades eran personalizadas, sería más fácil y flexible escribir el sistema desde cero aprovechando los marcos de desarrollo existentes y componentes de terceros.Mirando hacia atrás, esto funcionó muy bien para nosotros porque teníamos el tiempo y la habilidad, pero generalmente no es la mejor solución dependiendo de su modelo de negocio/contrato.

Ya no estoy en esa empresa, sin embargo, todavía usan mi software exclusivamente y me fui en excelentes términos.Estaré encantado de responder cualquier pregunta general que tengas y ayudarte a orientarte en la dirección correcta.

Arquitectura del sistema

Aquí hay una descripción general de alto nivel de en qué consistía el sistema:

• Dispositivos celulares personalizados que tenían entradas genéricas para acomodar múltiples instrumentos de diferentes tipos. (analógico, digital, presión, amperaje, flotadores, etc.)
• Las unidades enviaron paquetes UDP/TCP de formato personalizado a través de la red celular (GPRS) a nuestros servidores (Servidor de windows 2003 R2).Se envió información periódicamente para generar informes y sobre cambios de estado personalizables que podrían programarse en el dispositivo o en línea. (la configuración enviada a través de la red celular).
• Un multiproceso personalizado .NETO aplicación que utiliza escuchas TCP/UDP que capturan paquetes entrantes (Varios cientos de miles por día), descifró encabezados personalizados y enrutó los paquetes sin mayor interpretación a la base de datos correcta (Algunos clientes requirieron su propio sistema independiente)
• A MicrosoftSQL 2005 base de datos que actuaba como cerebro de todo el sistema.Los paquetes fueron interpretados usando Funciones CLR y alarmas activadas automáticamente (según configurado), compiló informes y mantuvo un historial completo
• Una costumbre .NETO Aplicación para gestionar alertas mediante la realización de llamadas telefónicas, el envío de mensajes SMS y el envío de correos electrónicos.La lógica del teléfono fue manejada por un Tarjeta dialógica Intel a través de líneas analógicas usando una combinación de indicaciones grabadas y Texto a voz.
• 3 ASP.NET sitios:
  • Sitio orientado al cliente que les permitió administrar sus cuentas/subusuarios, rastrear alertas, configurar unidades y alertas, datos de gráficos, dispositivos de mapas, exportar informes, etc.
  • Sitio de ventas que permitía la distribución de material a los vendedores, seguimiento de dispositivos individuales, informes de estado de los dispositivos, etc.
  • Sitio de gestión interna que permitía la creación de cuentas de clientes, la configuración/construcción de unidades y todas las demás funciones administrativas según fuera necesario.
• También había un sistema de monitoreo interno personalizado para verificar el estado del sistema y alertar a los técnicos sobre los problemas según fuera necesario, ya que el sistema necesitaba estar activo las 24 horas del día, los 7 días de la semana.
• Además creamos un aplicación para iOS, a Sitio movil, y un servicio/cliente web personalizado (API) para permitir la recuperación de datos de clientes directamente por parte de los clientes para permitirles integrar nuestra solución con sus existentes (generalmente personalizado) Sistemas SCADA.

Esos son los componentes que utilizamos y funcionaron.Haciéndolo de nuevo cambiaría un par de cosas.yo usaría Servidor Windows 2008 R2, SQL 2008 R2, y en lugar de una tarjeta Dialogic usaría Microsoft Dime utilizando VoIP.Yo también usaría Luz plateada en lugar de ASP.NET.Realmente me gusta ASP.NET, pero Silverlight puede ofrecer una presentación mucho mejor y puede usarse fuera del navegador según sea necesario, una solicitud común de los operadores de SCADA.

Todos los sitios utilizados Componentes de terceros para que los gráficos y las tablas no tuvieran que escribirse desde cero.Hay algunos componentes específicos de SCADA. (basado en gran parte en Java) allí afuera.Sin embargo, descubrimos que la mayoría de ellos eran toscos, feos o demasiado específicos para usarlos en nuestro sistema genérico. (¡también caro!Era más fácil y flexible personalizar un paquete de medidores/gráficos para "hacerlo" propio)..

Como se mencionó, El cerebro del sistema era la base de datos..Esto se hizo porque Microsoft SQL es un producto bastante impresionante y con buen soporte, diseñado para tiempos de actividad extremos con excelentes opciones de respaldo y rendimiento.También quedamos muy impresionados con el Integración .NET CLR eso fue posible permitiendo que nuestro código .NET personalizado se ejecutara como parte de ese proceso.Las unidades que estábamos apoyando venían en una variedad de modelos y podían configurarse para usar cualquier combinación de instrumentos, por lo que mantener la base de datos flexible era clave. ¡Usamos mucha normalización!

Una cosa que realmente ayudó fue usar CTE recursivos fingir la existencia de datos cuando los valores todavía eran los predeterminados.Hicimos esto para ahorrar espacio en la base de datos, pero también nos permitió introducir una capa de abstracción en la base de datos que permitió que las consultas también fueran flexibles.

Habíamos jugado con OPC en el pasado pero lo encontramos demasiado inflexible, difícil e irritante para nuestras necesidades.Pero eso fue hace unos años y no lo he vuelto a mirar desde entonces.

Esa es una respuesta larga y muy general a su pregunta.No puedo darle un código específico ni entrar en detalles extremos ya que esa información es propiedad de esa empresa, pero puedo responder algunas preguntas de diseño e indicarle marcos/herramientas que consideramos útiles.Mi principal consejo sería Divida todo en componentes separados y emplee el modelo de caja negra en cada uno para que los componentes individuales puedan intercambiarse o mejorarse según sea necesario..De lo contrario, el alcance del proyecto puede parecer abrumador.Déjame saber si tienes más preguntas o quieres más información, ¡buena suerte!