ITAN20090055A1 - SYSTEM FOR SIGNAL ACQUISITION AND AUTOMATIC REACTION IN SAFETY SYSTEMS - Google Patents

Description

DESCRIPTION

â € œSystem for signal acquisition and automatic reaction in security systemsâ €,

TEXT OF THE DESCRIPTION

The present invention relates to safety systems, and in particular relates to a system for the acquisition of signals by safety devices and the automatic reaction programmed on safety devices.

For a long time now, security systems, especially those dedicated to the control of medium and large areas, have normally been managed by computer systems, starting from a simple more or less dedicated machine to get to complex network structures. A significant problem in the control and management of this type of systems is still today constituted by the fact that often many of the devices that are used in the safety system can pre-exist the management program, creating obvious difficulties from the point of view compatibility. In practice, a security system that provides for the use of audio / video detection devices, tracking devices, alarm signaling devices or the like that are already supplied to the area on which the system is to be applied, needs to acquire the communication interface with such devices as correctly as possible. At the computer level, this interface is guaranteed by software known as drivers. The drivers of a given device are born with the device itself, and have the problem of being compatible in different ways to different programming environments. This obviously seriously compromises the possibility of using pre-existing devices for the implementation of new security systems management programs.

The purpose of the present invention is therefore the realization of a system that allows the acquisition of a signal through a plurality of sensor devices and the consequent automatic reaction of actuator devices, in which the communication between the system and said devices is complete and effective, and interoperability is guaranteed regardless of the origin of the devices themselves.

The object of the present invention is therefore a system for the acquisition of the signal from sensor devices and the automatic reaction by means of actuator devices, comprising a kernel module interfaced with an application programming interface (API) comprising a basic object for the realization of subsystem drivers, and an interface for each category of sensor devices and actuator devices, called application programming interface allowing the creation of a dynamic loading library (DLL) that includes said subsystem drivers.

In a preferred embodiment, said subsystem drivers allow communication between a given subsystem of devices and the kernel of the system according to the present invention.

Further advantages and characteristics of the present invention will become evident from the following detailed description of an embodiment of the same rendering, by way of non-limiting example, with reference to the attached drawings, in which:

Figure 1 is a schematic diagram showing the structure of the system according to the present invention;

figure 2 is a schematic diagram showing the communication between two elements of the system according to the present invention;

Figure 3 illustrates an example of a communication protocol between two elements of the system of the invention; And

figure 4 is an example of communication according to the protocol of figure 3.

A system that allows the acquisition of data and signals from various peripheral management subsystems and allows their management (monitoring and control) according to configurable action and reaction policies.

As it will be clear from the following, abstracting the concept of â € œcategoryâ € (of sensors and actuators) and defining the concept of SID (Subsystem Intelligent Driver), the system according to the invention allows the management of peripheral units, homogeneous from the point logically, but interfaced to the system through completely different hardware and software adapters.

The different devices are grouped homogeneously according to groups of functionality. Each category therefore represents a very specific functionality and each device (or an entire subsystem) can belong to one or a finite set of different categories.

The system is designed to work preferably in a security, anti-intrusion and video surveillance environment in which the following categories of logical input / output devices can be identified, which will in any case be described in more detail below.

Digital Input: Two finite state input system: On, Off (e.g. Tamper, Switch, etc.)

Digital Output: 2 finite state output system, (eg Relay)

Trackers: Tracking device (position in polar or Cartesian coordinates).

Serial Serial communication devices

OCR Devices that provide alphanumeric readings extracted through OCR

PTZ PTZ pointing devices related to pan / tilt (ex. Those used for cameras).

DVR Digital Video Recorders (digital video recording channel managers).

Alarm Managers Alarm managers.

Figure 1 presents a simplified scheme of the architecture which highlights the software layers involved. The system, hereinafter referred to as SARA (Signal Acquisition and Reaction Automation) implements a Kernel module indicated with 1 which takes care of managing all the other modules according to the directives and rules stored in the configuration of the system that will reside on the XML database.

Through direct interfacing with the Category Manager 101 and the storage system 201, the Kernel is able to implement all its functions. The SARA system kernel is developed using the SARA API software layer indicated with 2.

All subsystem drivers (SIDs) that are built using the API will therefore be compatible with the Kernel.

The API of the SARA system provide a base object 102 which can be `` derived '' (in the C language meaning of the term) to expand its functionality and which once started (from the Kernel) becomes an independent execution unit ( thread) which resides in the same memory space as the SRK.

In addition to the basic object 102, the APIs provide the developer with an interface 112 (C) for each category of sensors / actuators that are identified in the next paragraph. These interfaces allow the sending of events to the Kernel and the reception of the implementation commands.

The API of the SARA system allows the creation of the DLL (dynamic loading library) 103 which contains the SID 3 according to the format compatible (naming, entrypoint convention) with the Kernel.

The categories of logical units (subsystems) that can be managed by the SARA system are described below. As will be clearer in the following, each category of devices is managed through a single module so that the system Kernel must see a list of homogeneous devices from the point of view of functionality without having to worry about knowing exactly how to communicate and interconnect to the different ones. subsystems.

Digital Input

A â € œdigitai inputâ € is a logical device that allows the reading of 2 states: On, Off. This device can reside physically on different subsystems. For example, a digital input can be either interconnected to a control panel (Micro 5, Aritech, _) or to a video server (eg VideoBridge Indigo or VideoServer ACTI).

Digital Output

A â € œdigitai outputâ € is a logic device that allows the implementation of a state transition on 2 possible states: On, Off. This device can reside physically on different systems. For example VideoBridge, Micro 5.

Tracker

A Tracker (TRK) is a logical device that produces a set of coordinates relating to one or a set of objects identified by it (radar, sonar). A system of this type usually sends the coordinates of the object according to a Cartesian or polar reference.

Serial

A Serial device is a manager of serial ports that can reside on a videobridge, on a terminal server or directly on the machine.

OCR

An OCR reading system can be a more or less complex device that allows the extraction of one or more strings from digital images. The SARA system, in relation to this module, simply takes care of acquiring the data relating to the OCR reading carried out by the subsystem. This reading may consist of one or a set of strings based on the type of gate: for example, an OCR reading subsystem can only read the front plate of vehicles, or perform more complex readings such as scanning the ISO codes of containers. .

PTZ

A logic device of the PTZ type is an actuator that consists of a movable joint that sets its own positioning according to a triad of PTZ coordinates: Pan, tilt, Zoom or even through only one of the three: The device is typical of pan and tilt systems of antennas and cameras. The physical interconnection of a device of this type to the SARA system

it will be masked through the appropriate driver.

DVR The Digital Video Recorders are units that allow the recording of video streams in digital format

Alarm Manager

To this category belong those subsystems that allow the management of alarms, that is, they realize the following functions:

- Organization of alarms by alert areas

- Enabling of alert areas

- Disabling the warning zones

- Alarms storage on database

Management of the logical state of the alarm: Active, Acknowledged, etc.

- Assignment of alarms to one or a group of operators who can make the transition of state - Display of alarms on an integrated synoptic panel

- System user management

A system of this kind is for example Secure Perfect. If this subsystem is interconnected directly to other signaling sources, the alarms generated by the latter can be intercepted and forwarded to the SARA system, which will make the use it deems most appropriate based on the set of rules that have been defined when configuring the system.

An Alarm Manager is also a subsystem that manages devices that allow detection and forwarding to other alarm units. Such a device is capable of sending a data structure of the type AlarmCode: Alarm code to external systems

Timestamp: Time instant of alarm generation Description: Textual description of the alarm generated.

As previously mentioned, the SARA API also makes available to the SID developer the necessary infrastructure for the creation of the DLL that encapsulates the SID.

According to the diagram in figure 2 there will be an entrypoint 203 for each interface 112 which is extended by the SID developer and an entrypoint 303 for the base interface 102.

the realized SID 3 component, incorporated in the dynamic loading library (DLL) 103, will expose to the outside a series of access points (entrypoints) 203, 303 that the Kernel 1 of the SARA system will be able to dynamically connect to the modules which need to listen for events via callbacks and to send commands via asynchronous methods, via interface pointers 301.

More precisely, each SID manages a (more or less complex) sub-system to which different types of actuator sensors are interconnected.

Each â € œsub-systemâ € exposes to the Kernel a list of devices that it can control: at least 1. A subsystem manages different sensors / actuators belonging to different of the categories listed above.

As will be evident in the following, the development APIs provide the programmer with a set of interfaces (C classes) to be derived in order to allow the latching of events and commands between the SID and the SARA Kernel.

Creating a SID for the SARA system means:

1. Create a Win32 DLL type library.

2. Extend an object of the CSID type and the interfaces relating to the categories of actuator sensors that you intend to manage with the driver.

3. Configure the new component appropriately in the SARA system.

The SARA system provides some development APIs that allow the creation of SIDs. These APIs consist of the following files:

1. SIDDllEntry.h

2. SaraAPI.h

3. SaraAPI.dll

The Kernel loads the Win32 dii dynamically: at run time only if configured from the SARA database. Once verified that the content of the dynamically loaded library is compatible with the architecture of SARA (verification of entry points), then it is loaded into memory and the object defined in it is instantiated as many times as there are subsystems that you can manage with it.

It is important to note that the objects defined in the DLLs loaded by the SARA system can be instantiated multiple times. This means, for example, that if the plug-in for the monitoring and control of a digital input central such as Aritech is created, the SARA system can instantiate this object N times, setting N different configurations, for the control of N Aritech control panels compatible with each other.

Communication with the Kernel occurs through the following means:

1. DATA CALLBACKs for sending data or spontaneous reports from the SID to the Kernel.

2. SYNC METHODs for synchronous requests, settings and initialization by the Kernel on the SID.

3. COMMAND EVENTs (asynchronous requests) to be managed by overriding appropriate methods (COMMAND HANDLERs) already made available by the architecture.

4. RESP CALLBACKs for response to asynchronous requests.

5. LOG CALLBACK for sending log messages.

6. ERROR CALLBACK for reporting system errors.

Figure 3 shows the case in which a SID 3 implements two types of interfaces: DI and TRK, which are each split into an event interface 122 and a query interface 132. This means that the subsystem managed by this SID controls N output devices digital and M tracking devices (ex. CEDAR or SONAR or GPS cameras ...). Kernel 1 through the synchronous methods of the basic CSID interface initializes, instantiates the object and starts it. In fact, extending the CSID interface means having created an independent thread. Depending on its execution logic, SID 3 uses the DATA CALLBACK, indicated with 401, to send data to the Kernel spontaneously.

To implement the asynchronous â € œRequest - Responseâ € mechanism between Kernel and SID, the Kernel transparently starts a method (command handler) to the SID developer for which it is necessary to perform the override. If the override is not carried out, the command is still managed by the system architecture but, clearly, nothing is implemented on the peripherals of interest.

Example: For the digital output, the following command handler linked to the SID DO Interface must be overridden

void OnOpenDO (.)

void OnCloseDO (.)

Once the code related to the previous two command handlers have been written, the callback DOResponseCallback () can be called to communicate the outcome of the command execution.

Figure 4 explains the â € œRequest - Responseâ € mechanism implemented in the SARA system architecture: once a SID 3 has been started, it executes its own thread that listens for system messages. A specific type of message is defined for each Kernel 1 command. When a command execution request message arrives, the thread starts the command manager 403 responsible for executing this execution.

Kernel 1 continues its execution in asynchronous mode but expects to receive an answer 20 (affirmative or negative) with the result of the command within a certain time interval. SID 3 then takes care of confirming the execution of a command through the appropriate RESP CALLBACK. Each command is numbered so that the Kernel can match the request to the response.

Conceived in this way, the system allows for signal acquisition and automatic reaction by means of sensor devices and actuator devices regardless of their origin and whether their respective specifications are originally compatible with the system intended to manage them.

Claims (5)

CLAIMS 1. System for the acquisition of the signal from sensor devices and the automatic reaction by means of actuator devices, comprising a kernel module interfaced with an application programming interface (API) comprising a basic object for the realization of subsystem drivers, each subsystem comprising a given category of sensor or actuator devices, and an interface for each category of sensor devices and actuator devices, said application programming interface allowing the creation of a dynamic loading library (DLL) which includes said subsystem. System according to claim 1, wherein said subsystem drivers allow communication between a given subsystem of devices and the kernel of the system according to the present invention. System according to claim 1 or claim 2, wherein said dynamically loaded library which incorporates said subsystem driver communicates with said kernel through a plurality of access points which are interfaced with a plurality of interface pointers present in said kernel . 4. System according to claim 3, in the communication between said kernel and said subsystem driver follows a request and response procedure comprising the sending of a given request by the kernel and the implementation by the active component of the subsystem driver of a given response message. System according to claim 3 or claim 4, wherein the communication between Kernel and driver takes place by the following means: DATA CALLBACKs for sending spontaneous data or signals from the subsystem driver to the Kernel; SYNC METHODs for synchronous requests, settings and initialization by the Kernel on the subsystem driver; COMMAND EVENTs (asynchronous requests) to be managed by overriding appropriate methods (COMMAND HANDLERs) already made available by the architecture; RESP CALLBACKs for response to asynchronous requests; LOG CALLBACK for sending log messages; ERROR CALLBACK for reporting system errors.