Algunos aspectos de la construcción de sistemas de seguridad integrados. Arquitectura de sistemas automatizados.

Algunos aspectos de la construcción de sistemas de seguridad integrados. arquitectura de sistemas automatizados..

KOROLEV Vladimir Sergeevich

Algunos aspectos de la construcción de sistemas de seguridad integrados. arquitectura de sistemas automatizados

Fuente: revista «Special Equipment» N° 4 2007
 

Tarde o temprano, los funcionarios responsables de la seguridad de la instalación encomendada se enfrentan al problema de elegir un sistema de seguridad automatizado. Y no importa en absoluto si esto sucede en la fase de diseño o durante el funcionamiento. Es bueno si hay recomendaciones departamentales que al menos de alguna manera limiten y reduzcan el espacio de búsqueda. ¿Y si no? Con tanta abundancia de ofertas publicitarias, hermosas interfaces y promesas de montañas de oro. ¿Qué criterios se deben seguir? Y si tenemos en cuenta que el presupuesto siempre es limitado, ¿cómo conseguir la máxima calidad al mínimo coste?

Comparar varios sistemas automatizados de seguridad de instalaciones, la gran mayoría de los cuales se denominan con orgullo sistemas de seguridad integrados (ISS), es una tarea realmente difícil. Y el punto aquí es este. Por ejemplo, a nadie se le ocurriría comparar una bonita casa con jardín con un edificio gris de cinco plantas o un moderno rascacielos. Y más aún hacer la pregunta − cual es mejor? Pero en el campo de los sistemas automatizados de seguridad de instalaciones, esta situación ocurre con bastante frecuencia. Porque detrás de un hermoso caparazón, un conjunto de frases «intensivas en conocimiento», a veces es muy difícil discernir qué es realmente el sistema «Y» y cuál es su área de aplicación preferida.

El proceso de desarrollo y construcción de un sistema automatizado es muy similar a la construcción de un edificio: La construcción de ambos es un proceso complejo y laborioso, a menudo con resultados impredecibles (presupuesto, plazos, desviaciones del proyecto, etc.). Y si consideramos un sistema automatizado como una unidad de partes interconectadas y ubicadas naturalmente que resuelven un problema común, entonces la respuesta a la pregunta de cómo será al final del desarrollo y qué propiedades de consumo tendrá, en primer lugar estar determinado por su arquitectura. Porque es la arquitectura la que describe los componentes del sistema y sus relaciones, determina los principios de desarrollo, mejora y soporte, y determina la clase de objetos sobre los que su uso será más efectivo. Siguiendo la analogía con la construcción, podemos decir que la arquitectura de un edificio residencial diseñado para Egipto o Arabia Saudita probablemente no sea adecuada para Siberia.

Desgraciadamente, un tema tan urgente como la construcción de sistemas integrados de seguridad en las instalaciones sigue estando bastante poco tratado en la actualidad. Y, en general, hay muchos espacios en blanco en esta área: cuestiones de estandarización, terminología, clasificación de medios técnicos, arquitectura de sistemas − Todo esto requiere la mayor atención y un análisis cuidadoso. El propósito de este artículo − Considere algunas cuestiones relacionadas con la arquitectura de los sistemas automatizados de seguridad de las instalaciones.

El resultado de la búsqueda de la frase “sistema de seguridad integrado” no fue nada sorprendente. Está claro por qué un motor de búsqueda arrojó inmediatamente alrededor de mil enlaces y el segundo aún más. Hoy en día se llama HMB a todo lo que es un ordenador al que se le conecta algún tipo de dispositivo de alarma y cámara de televisión.

Dada la complejidad del tema en discusión, aún es necesaria una definición más estricta. Sistema de seguridad integrado − Se trata de un conjunto de medidas organizativas y técnicas que permiten, sobre la base de software, hardware y software universales, realizar la recepción automatizada, entrega garantizada y visualización de información cuando se detecten situaciones potencialmente peligrosas en puntos controlados para tomar medidas oportunas. para prevenirlos y reprimirlos [1]. La base del ISIS es un sistema automatizado (AS), que combina en un solo todo los medios de seguridad perimetral, control de acceso, vigilancia televisiva, etc., es decir, todo lo necesario para garantizar el funcionamiento seguro de la instalación. Por lo tanto, en este caso, cuando hablemos de cuestiones arquitectónicas, hablaremos exclusivamente de sistemas automatizados y las características de su construcción.

El siguiente paso es seleccionar el tipo de objetos sobre los que los altavoces muestran todo su potencial. Tiene sentido considerar sistemas automatizados que se coloquen según lo previsto para objetos grandes, importantes y particularmente importantes. Porque es precisamente en estos objetos donde se debe implementar plenamente la funcionalidad declarada y revelar al máximo las capacidades de los sistemas, sus fortalezas y debilidades.

La tarea principal resuelta al proteger el objeto − Se trata de advertir y prevenir el ingreso de intrusos a la instalación, así como prevenir acciones no autorizadas de intrusos tanto externos como internos en relación con la infraestructura, la propiedad y el personal de la instalación. Por lo tanto, un sistema automatizado de seguridad de instalaciones debe considerarse como una herramienta especializada, un conjunto de herramientas que ayuda a los servicios de seguridad, unidades militares y paramilitares a resolver problemas relacionados con la protección de instalaciones.

Este enfoque nos permite formular criterios para evaluar las capacidades potenciales de varias soluciones arquitectónicas, siempre que los sistemas en cuestión tengan aproximadamente la misma funcionalidad:

• fiabilidad, como la capacidad de un sistema mantener su funcionalidad si sus componentes fallan y garantizar la entrega garantizada de mensajes para evitar la pérdida de información sobre eventos importantes;

• escalabilidad, como aumentar la funcionalidad del sistema durante su funcionamiento sin detener el trabajo .

A partir de datos publicados abiertamente, es imposible realizar un análisis completo y comparar diferentes soluciones en todos los aspectos, por ejemplo, analizar el proceso de interacción de los componentes y evaluar los flujos de datos. Por tanto, en este caso se utilizó una metodología basada únicamente en el análisis cualitativo. En el siguiente texto no se hace referencia a sistemas de fabricantes específicos, porque el objetivo no es comparar sistemas específicos y decir cuál es mejor, cuál es peor, no. El objetivo es analizar las capacidades potenciales de las soluciones utilizadas e intentar evaluar las tendencias generales en el desarrollo de la arquitectura de los altavoces modernos.

Fabricantes de sistemas automatizados domésticos [2 − 9], seleccionados por las razones expuestas anteriormente, son sorprendentemente unánimes en al menos una cosa. Todos ofrecen sistemas distribuidos en red, que son, en esencia, sistemas automatizados de control de procesos. Todas las opciones consideradas, con pequeñas diferencias, se construyen según el mismo esquema: nivel superior − toma de decisiones y visualización de información, nivel intermedio − conversión de protocolos e interfaces, menor − nivel de controladores periféricos que controlan medios técnicos (Fig. 1).

Los niveles superior e inferior de los sistemas considerados son estructural y funcionalmente casi idénticos. El nivel superior consta de varios tipos de estaciones de trabajo automatizadas (AWS), servidores de bases de datos, etc., integrados en una red local basada en la familia de protocolos TCP/IP. En el nivel inferior hay controladores periféricos que interactúan directamente con los medios técnicos. La interacción con el nivel medio se realiza, por regla general, a través de RS485, aunque a veces se utiliza RS232.

De mayor interés es la solución arquitectónica de nivel medio, que es clave y determina las características principales y más importantes del funcionamiento del sistema. Ya no hay unanimidad aquí y las opciones presentadas se pueden reducir a las tres siguientes (Fig. 2):

• gestión centralizada basada en un controlador o servidor multifuncional (opción a);

• gestión descentralizada basada en una estación de trabajo o servidor especializado (opción b);

• sistemas peer-to-peer sin gestión centralizada (opción c)*.

*) A pesar de que cada fabricante tiene su propia terminología, esto no cambia la esencia del asunto.

La opción de diseño del sistema que se muestra en la Fig. 2a es el más común. Lo más probable es que, históricamente, el sistema «creciera» a partir del controlador. Al parecer, primero se desarrolló o compró un determinado dispositivo multifuncional y, posteriormente, a medida que crecieron las necesidades del cliente y la complejidad de las tareas a resolver, se le agregaron el equipo y el software necesarios. Como resultado, el desarrollador se vio rehén del problema de garantizar la compatibilidad ascendente, donde con el lanzamiento de cada versión posterior, realizar cambios fundamentales se volvió cada vez más costoso y problemático. Esta hipótesis se apoya en el hecho de que, en la mayoría de los casos, se utiliza RS-232 como interfaz de comunicación con el servidor, que bien podría usarse para la configuración inicial del controlador y la transmisión periódica de pequeños bloques de datos, pero nada más. .

Todo lo que pueda romperse, eventualmente se romperá. A pesar de todas sus ventajas, esta solución arquitectónica no es la más eficaz en términos de fiabilidad. En este esquema, el cuello de botella es el controlador, en el que se concentra toda la lógica de negocios para el funcionamiento del objeto protegido, y si falla, las consecuencias pueden ser muy graves (si la lógica de negocios se distribuye entre el servidor y el controlador , la situación puede ser aún peor). Este hecho implica la presencia de mayores requisitos para el software del propio controlador, mayores requisitos para los controladores periféricos y la necesidad de utilizar complejos esquemas de redundancia.

El siguiente mayor cuello de botella en este esquema es el servidor, que probablemente almacena una copia de seguridad de la base de datos (modelo de objetos) y proporciona una interfaz al nivel superior. El servidor debe sondear periódicamente al controlador para obtener información sobre el estado actual de los puntos controlados y transmitirla a los nodos «interesados». Lamentablemente, en este caso, es casi imposible garantizar el funcionamiento dentro del modelo de evento y en tiempo real debido a las limitaciones inherentes al RS-232.

Cabe señalar que un sistema construido de esta manera es completamente insensible a fallas en la red local y otros equipos de nivel superior. Incluso si asumimos que la red local se verá interrumpida, el controlador seguirá funcionando.

Hay modificaciones a este esquema. Por ejemplo, cuando un servidor controla varios controladores. Esta solución es más efectiva que la discutida anteriormente, pero sin embargo, aquí, como en cualquier otro sistema centralizado, existe una probabilidad muy alta de una «caída» de todo el sistema en su conjunto.

En cuanto a la escalabilidad de los sistemas construidos sobre la base de esta solución arquitectónica, se aplican las siguientes observaciones. Primero, al agregar nuevos equipos de nivel inferior, será necesario realizar cambios en la base de datos del controlador. En la mayoría de los casos, esta acción implica un reinicio posterior del controlador, lo que, de hecho, equivale a un reinicio de todo el sistema en su conjunto. Sin embargo, en una instalación operativa grande, un evento de este tipo está asociado con serias dificultades organizativas. En segundo lugar, puede deshacerse de los reinicios implementando alguna versión de la tecnología «plug and play». Esto definitivamente conducirá a un software más complejo y, en consecuencia, a un aumento en la cantidad de errores y a un aumento en la probabilidad de un funcionamiento inestable del controlador. En tercer lugar, la situación se simplifica considerablemente en el caso de una gestión centralizada del servidor por parte de varios controladores, porque en este caso, sólo es necesario reiniciar la parte modificada del sistema.

Solución arquitectónica implementada según el diagrama mostrado en la Fig. 2b, implica la presencia de varios nodos iguales, cada uno de los cuales controla su propio conjunto de equipos de nivel inferior (controladores periféricos). En este caso, el elemento de control puede ser un lugar de trabajo automatizado o un servidor dedicado.

Vale la pena señalar que existe un esquema en el que el lugar de trabajo automatizado interactúa con un controlador multifuncional, que , a su vez, controla los controladores periféricos. Este esquema es una variación de la solución de la Fig. 2a y discutido en detalle arriba.

Esta solución podría clasificarse como un sistema peer-to-peer (Fig. 2c). Sin embargo, un esquema con una estación de trabajo de control o un servidor tiene sus propias características fundamentales y, por lo tanto, se considera una opción independiente para construir un AS, que se encuentra con bastante frecuencia en la vida real.

El esquema con el servidor como elemento de control no tiene ventajas ni desventajas especiales. Las desventajas de esta solución son, por un lado, el mayor coste respecto a otras y, por otro, la necesidad de reservar un elemento de control. Además, la principal contribución al costo provendrá no tanto del equipo y el software de aplicación, sino del costo de los sistemas operativos del servidor y DBMS más el costo de las licencias de los clientes. Si imaginamos que hay varios nodos de control de este tipo en el sistema y que cada uno de ellos funciona para un cierto número de clientes, incluso un cálculo básico da una cantidad muy decente. La necesidad de redundancia estará determinada por los requisitos del cliente y el método de construcción del nivel inferior (el grado de «inteligencia» de los controladores periféricos). En el caso más sencillo (una solución de este tipo se utilizó en uno de los sistemas), la redundancia es realmente necesaria y el desarrollador la ofrece como opción.

La solución que menos éxito tiene es la opción en la que se utiliza un lugar de trabajo automatizado como elemento de control. Si este elemento falla, el objeto protegido puede encontrarse en una situación muy difícil, por ejemplo, parte del perímetro quedará desprotegida o un conjunto de puntos de acceso dejarán de funcionar. Lo peor de esto es que el personal al momento del accidente quedará sin “ojos”, porque Tanto el control del equipo como la visualización de información para el operador están «cerrados» a un solo elemento. La única salida a esta situación − Este es un modo de espera «caliente». Sin embargo, este paso no resuelve completamente todos los problemas potenciales inherentes a este esquema.

Posibilidad de escalar un sistema con la arquitectura mostrada en la Fig. 2b, es significativamente superior al del esquema anterior con control centralizado basado en un controlador. Idealmente, al agregar nuevos equipos, solo necesita exportar la base de datos modificada a la estación de trabajo o servidor apropiado. Este esquema le permite implementar de manera muy simple un reinicio del software, sin detener la operación y reiniciar el elemento de control.

En comparación con otros, los sistemas peer-to-peer (Fig. 2c) tienen perspectivas más serias en sus capacidades. En tales esquemas, el controlador actúa como un nodo de red igual que gestiona su pequeña parte del objeto protegido. Esta solución permite un enfoque bastante flexible para la construcción de todo el AS, distribuyendo los controladores de tal manera que se minimicen las consecuencias de una falla de cada rama individual. Sin embargo, esta solución, como otras, tiene un inconveniente típico: − falta de modo en tiempo real, debido a la necesidad de «pulir» al organizar la interacción con los controladores periféricos. Desafortunadamente, esta implementación no permite el uso completo de las capacidades potenciales de los sistemas peer-to-peer.

Desde el punto de vista de la escalabilidad, este esquema no es diferente del esquema en Higo. 2b, y aquí son válidos todos los comentarios realizados anteriormente.

Considerando varios aspectos de la moderna «ingeniería de controladores», podemos decir inequívocamente que durante la última década se han observado dos tendencias estables. En primer lugar, debido al rápido desarrollo de la microelectrónica y la tecnología de microprocesadores, así como al costo cada vez menor de los componentes electrónicos, el nivel de «inteligencia» de los controladores está aumentando. En segundo lugar, el desarrollo concomitante de la tecnología de la información «estimula» la integración de controladores en diversos instrumentos y dispositivos, dándoles nuevas características de calidad y funcionalidad que antes no estaban disponibles, concentrando la «inteligencia» en el lugar de su uso, es decir, exactamente donde realmente se necesita. El ejemplo más claro de esto − Nueva generación de electrodomésticos. Un panorama similar se observa en el mercado de los sistemas de seguridad: herramientas de control de acceso, equipos técnicos de seguridad, etc. Han aparecido dispositivos que, cuando se utilizan, no solo pueden mejorar significativamente las características tácticas y técnicas de los sistemas, sino también reducir su costo, por ejemplo, minimizando el costo de los productos de cable. Además, los controladores modernos tienen la capacidad de funcionar en una red local, actuando como nodos independientes e iguales. Esto da motivos para creer que pronto aparecerán soluciones en el campo de los sistemas de seguridad automatizados que aprovecharán plenamente el potencial de los sistemas peer-to-peer. A modo de ilustración, podemos dar un ejemplo del intenso desarrollo del mercado de los sistemas de soporte vital y la automatización de edificios con el inicio del uso de tecnologías de bus de campo. Los estándares conocidos y ampliamente utilizados en este campo, como BACNet y LonWorks, se basan en conceptos de bus de campo que surgieron de lo más profundo de la industria.

Basándose únicamente en los datos publicados, es imposible formarse una opinión informada sobre las características de la implementación del software de los sistemas en cuestión. Por lo tanto, con base en la metodología antes mencionada y el análisis de las tendencias actuales en el campo de las tecnologías de la información, intentaremos formular requisitos para la arquitectura de software, teniendo en cuenta las características de esta área temática. Como criterios adicionales, además de la confiabilidad y la escalabilidad, es necesario considerar la seguridad y la interoperabilidad como la capacidad de integrar en el sistema módulos o subsistemas de software desarrollados independientemente [17].

Hoy en día, existe una gran cantidad de tecnologías para construir sistemas automatizados distribuidos con paradigmas tanto de procedimiento como de objetos para garantizar la interacción de los elementos constituyentes: RPC (llamada a procedimiento remoto), Java RMI (invocación de método remoto), CORBA (arquitectura de solicitud de objeto común) , modelo de objetos DCOM (arquitectura de componentes distribuidos), etc. [10, 11] La solución arquitectónica más prometedora hoy en día se considera − SOA (arquitectura orientada a servicios), especialmente en combinación con ESB (bus de servicios empresariales) y EDA (arquitectura impulsada por eventos), desarrollada por un grupo de corporaciones lideradas por IBM y Microsoft [12 − 15].

Cada una de las tecnologías enumeradas tiene sus pros y sus contras y está «dirigida» a un área de aplicación específica. Sin embargo, a pesar de las diferencias en la implementación, las tecnologías enumeradas tienen mucho en común, lo que nos permite identificar tendencias generales y seleccionar soluciones probadas. Las características más importantes, implementadas en un grado u otro en todas las tecnologías, son:

• paradigma de acceso a datos de objetos (servicios), que permite la abstracción de la naturaleza física del objeto;

• una forma unificada y abstracta de describir objetos;

• “almacenamiento” de objetos, como forma de obtener una referencia a un objeto;

• interacción a través de mensajería;

• transporte independiente, método de interacción sincrónico o asincrónico ;

• autobús de servicio − una capa de software (middle ware) que proporciona acceso unificado a los datos.

Basándonos en las tendencias en el desarrollo de la tecnología de la información y teniendo en cuenta los requisitos específicos de los sistemas automatizados de seguridad para objetos, podemos formular los requisitos básicos para la arquitectura del software:

• el sistema debe ser construido como un sistema distribuido heterogéneo con ciertas reglas fijas de acceso a los datos;

• el sistema debe construirse sobre un principio jerárquico con diferenciación de la funcionalidad de los niveles constituyentes;

• el nivel de control debe abstraerse completamente de la naturaleza física de los instrumentos y dispositivos utilizados, y operar únicamente con sus equivalentes lógicos;

• la interacción del nivel de control con los medios técnicos debe llevarse a cabo a través de una “capa” de software que proporciona una interfaz para dispositivos físicos específicos;

• los elementos del sistema deben operar con entidades comunes y funcionar dentro de un único modelo del objeto protegido;

• los elementos del sistema deben soportar un modelo de interacción de “evento”, informando sobre cambios en su estado;

• el sistema debe proporcionar un tiempo de respuesta específico al evento ocurrido;

• el intercambio de información debe realizarse mediante mensajes a través de un protocolo seguro con identificación obligatoria del suscriptor, entrega garantizada de mensajes y restablecimiento automático de la comunicación .

El análisis de varios métodos para construir sistemas automatizados nos permite concluir que en este caso, el óptimo y más satisfactorio de los requisitos enumerados es la versión del sistema implementada como un sistema distribuido punto a punto débilmente acoplado según la clasificación [ 10].

En este caso, “débilmente acoplado” significa que cada elemento (módulo) del sistema debe ser hasta cierto punto independiente y autosuficiente, lo que asegurará la operatividad del sistema en caso de falla de cualquier elemento (con su correspondiente disminución de la funcionalidad de todo el sistema en su conjunto). En otras palabras, el sistema no debe tener un elemento (grupo de elementos) cuyo fallo llevaría a bloquear el funcionamiento de todo el sistema en su conjunto.

El requisito de abstraer el nivel de control de la naturaleza física de los medios técnicos utilizados, así como el funcionamiento en modo de mensajería, se implementa más adecuadamente en una arquitectura cliente-servidor de tres niveles, cuando todas las solicitudes se realizan a través del servidor de aplicaciones. El nivel actual de desarrollo de las tecnologías de la información permite distribuir este servidor y colocar el software correspondiente en computadoras o controladores que proporcionan una interfaz con los medios técnicos. Al mismo tiempo, es posible reducir significativamente los requisitos de software de estación de trabajo (AWS) e implementarlos como una especie de clientes «ligeros». Esta solución permite no sólo minimizar el número de computadoras, sino también aumentar la confiabilidad al agrupar elementos que pueden bloquear el funcionamiento de varias partes del sistema.

Las características operativas del sistema dependen de la eficacia con la que se resuelvan los problemas de escalabilidad e interoperabilidad, porque la mayor cantidad de problemas comienzan a aparecer al agregar nuevos equipos «desconocidos» al sistema o al intentar integrar un subsistema de otro fabricante.

Los métodos modernos para resolver estos problemas implican el uso de diversas tecnologías de «enlace tardío» (enlace tardío, invocación de método) u obtener dinámicamente una referencia a un objeto de software, cuyos métodos y propiedades no se conocen en la etapa de diseño. Sin embargo, todas estas tecnologías, debido a su universalidad, no son triviales y son muy redundantes. Como resultado, se generan nuevos problemas adicionales, cuya solución requiere la participación de programadores altamente calificados y complica enormemente el sistema: en desarrollo, configuración y mantenimiento.

Una de las características del área temática que estamos considerando es que se limita a una gama muy específica de tareas y aquí no se requiere una universalidad «integral». Esto crea serias condiciones previas para optimizar la arquitectura. Para los sistemas automatizados de este tipo, existe una forma más sencilla y eficiente de cumplir los requisitos de escalabilidad e interoperabilidad: esto es para garantizar el funcionamiento del sistema en el marco de un modelo único del objeto protegido.

Descripción de los equipos que forman parte del sistema: equipos técnicos de seguridad, equipos de control de acceso, equipos de televisión, etc., ya que un conjunto de ciertos objetos de control abstractos interconectados (puntos de control) permite estandarizar, “legitimar” el acceso a los datos. mecanismo. Este enfoque permite, si es necesario, cambiar libremente las estructuras de datos internas y los algoritmos operativos sin afectar el correcto funcionamiento de todo el sistema en su conjunto.

Resumiendo lo anterior, podemos formular los requisitos para el modelo del objeto protegido y sus componentes:

• el modelo debe construirse a partir del conjunto mínimo requerido de componentes − objetos de control;

• cada objeto de control debe tener un identificador único;

• cada objeto de control debe representarse como una máquina de estados finitos y tener un conjunto fijo de estados ;

• cada objeto de control debe generar un mensaje del sistema cuando cambia su estado;

• el modelo de objetos debe ser escalable, es decir permitir la adición y eliminación de objetos de control durante la operación.

Los sistemas de seguridad integrados, como ya se señaló, por su finalidad son sistemas automatizados de control de procesos. Además, en el circuito de control de este proceso tecnológico, el papel principal y determinante lo desempeñan los seres humanos: los seres humanos. tomador de decisiones. El sistema solo proporciona información sobre el estado actual del objeto y, cuando surgen situaciones predeterminadas, controla equipos auxiliares: enciende la grabación de cámaras de televisión, iluminación adicional, etc. Por lo tanto, lo único que es importante para el sistema es si un sensor en particular se ha activado o no, si tal o cual dispositivo funciona correctamente, para poder informar rápidamente al operador sobre la ocurrencia de algún evento y tomar las acciones necesarias. Desde el punto de vista del sistema, el proceso tecnológico no sólo es discreto, sino que también se caracteriza por el hecho de que cada sensor o dispositivo (objeto monitoreado) tiene su propio conjunto de estados fijos y especificados.

Es aconsejable agrupar los medios técnicos utilizados para proteger objetos en dos grandes clases, que pueden denominarse puntos de control y puntos de acceso. La división propuesta refleja adecuadamente la esencia de los procesos en curso. Si no se tienen en cuenta detalles menores, en realidad circulan por el sistema dos flujos principales de información: el flujo de datos de control de acceso y el flujo de información de control y seguridad. Así, podemos hablar de puntos de acceso y puntos de control como componentes básicos del modelo matemático. Sin embargo, para construir un modelo matemático de un objeto o proceso, también es necesario especificar las relaciones entre los elementos que lo constituyen. Los puntos de acceso y control son sólo fuentes de señales que informan sobre la ocurrencia de algún evento significativo. Por tanto, es lógico utilizar el objeto “zona” como elemento conector. La zona, que es objeto de control tipo contenedor, permite no sólo agrupar puntos, sino también identificar de forma única la ubicación del evento.

Una ventaja adicional de este enfoque para construir un modelo es que los medios técnicos agrupados de tal manera, se prestan a una clasificación muy simple [16], correspondiente al paradigma de programación orientada a objetos.

Teniendo en cuenta que todos los objetos de control enumerados funcionan como máquinas de estados finitos, se puede argumentar que estos elementos son suficientes para construir un modelo matemático del objeto protegido, ya que, basándose únicamente en estos datos, es posible calcular sin ambigüedades el estado de el objeto en cualquier momento.

La situación es tal que los instaladores y los clientes finales ya no quieren convertirse en “rehenes” del fabricante del sistema “X” o “Y”. La implementación de los requisitos de apertura e interoperabilidad conducirá tarde o temprano al hecho de que los sistemas de seguridad automatizados serán una especie de SCADA, que integra equipos y subsistemas de varios fabricantes. Además, en algunos casos, será necesaria la integración con sistemas de soporte vital y automatización de edificios. Si esto es bueno o malo es una cuestión completamente diferente. Las implementaciones actuales de bajo nivel que utilizan tecnologías de bus de campo brindan fuertes razones para creer que este será el caso.

La escala y la complejidad de los sistemas no harán más que aumentar. Es posible construir un sistema abierto, confiable y seguro solo como resultado de su cuidadoso diseño y, por lo tanto, las cuestiones de la arquitectura de los sistemas de seguridad automatizados son cada vez más importantes y relevantes.

Literatura

1. Googe I.G. etc. Sistemas de seguridad integrados/Security World, 2001 – No. 12.

2. bolid.ru

3. sigma-is.ru

4. algont.ru

5. bezopasnost.ru

6. eleron.ru

7. nikiret.ru

8. dedal.ru

9. itrium.ru

10. E. Tannenbaum, M. Van Steen. Sistemas distribuidos. Principios y paradigmas. /SPb.: Peter, 2003.

11. D. Tocino, T. Harris. Sistemas operativos. Sistemas paralelos y distribuidos./SPb.: Peter, Kyiv: BHV Publishing Group, 2004.

12. Recién llegado E. Servicios web XML, WSDL, SOAP y UDDI. Para profesionales./San Petersburgo: Peter, 2006.

13. Leonid Chernyak. Una búsqueda del Santo Grial de la tecnología de la información./Open Systems, 2006 – No. 1(117).

14. Alexey Dobrovolsky. Integración de aplicaciones: métodos de interacción, topología, herramientas./Open Systems, 2006 – No. 9(125).

15. Gleb Ladyzhensky. Integración de aplicaciones tal como es./Open Systems, 2006 – No. 9(125).

16. V.S. Clasificación de componentes de sistemas de seguridad integrados./Equipos especiales, 2007 – No. 1.

17. Sergey Kuznetsov. Portabilidad e interoperabilidad de los sistemas de información y estándares internacionales./citforum.ru