Configuration files in Parking system

From VIT company
(Redirected from Configuration files)
Jump to navigation Jump to search

Configuration files

OSAPoliticsDefs.plist

To configure the logic of the application in different modes (TRANSMISSION - "skip all", "skip friend", etc.) user must properly set up the configuration file - ".. \ VIT \ Overseer Parking \ resources2 \ ui \ OSAPoliticsDefs.plist". The scheme is as follows –to each of the existing system events one can assign the appropriate response and group such events of influence spheres (all, friends, single group).
Record example:

"Group1" = [
1 = [
oper_sleep = [
car_store=;
];


car_let = [
car_store=;
gate_open = [
];


avmod_process = [
relay = [
gate_1 = [
value = 1;
time= 20;
];
];
];
avmod_process = [
relay = [
gate_2 = [
value = 1;
time= 200;
];
];
];


ev_rec = [
];
ask_user_hide = ;
];
];
];


friends = [
6 = [
after_store_action = [
];


car_lost = [
ev_rec = [
];
];


park_action = [
park_process=;
db_exec = [
];
];
]; //6
];


all = [
default = [
frame_saved = [
db_exec = [
];
];


make_snapshot = [
save_frame=;
];
];


Explanation:

First of all, the belonging to the spelled groups is checked (their policy is working), then to friends, then to all.

Parameters of the record in file OSAPoliticsDefs.plist

Events and reactions


Possible events:

  • car_tries_in - the car tries to enter ( number is recognized, direction= entry);
  • car_tries_out – the car tries to leave (number is recognized, direction= exit);
  • car_tries_unk - it is undefined what the car is trying to do( number is recognized, direction- undefined);
  • oper_sleep - the operator missed the car ( it came in and out);
  • car_let - the car was missed (the operator clicked the button skip in the alert);
  • car_no_let - the car was not skipped ( the operator closed the alert);
  • car_tries_change_dir - the car tries to change the direction ( the direction of the car movement is changes in the frame);
  • car_lost_in - the car has disappeared in the direction “entry”;
  • car_lost_out - the car has disappeared in the direction “ exit’';
  • car_lost_unk - the car has disappeared in the direction “ undefined”.


Possible reactions:

  • show_info- to show data about the car (alert);
  • hide_info- to hide data about the car (alert);
  • gate_open – give a signal to the control device;
  • car_store – save a machine (in the base of events);
  • car_let – skip the car (to the territory, recording in the statistics);
  • ask_user – ask the user what to do (аlert);
  • ask_user_hide – hide the window with the question (remove the previous alert).


Events and reactions. Additional features


The newest versions of Parking systems offer extended list of events and reactions to this events to be used in the configurational file:


New possible events:

  • after_store_action - number of vehicle was stored in the database;
  • frame_saved - frame was stored in the database without the plate number;
  • make_snapshot- snapshot (frame) from camera was made;
  • no_recognize - nothing was recognized on the appropriate command;
  • car_manual_capt - user pressed the "Identify" button;
  • start_lpr - recognition process was started on demand;
  • inspector_init - viewport initialization;
  • car_confirm_dir - used chose some movement direction of the vehicle;
  • car_ask_dir - an alert for movement derection selection is required;
  • park_action - car is trying to enter to/exit from the parking lot;
  • user_press_space or user_press_Escape - user pressed buttons "space" or "Esc".


New possible reactions:

  • ask_test_allert_type - to ask allert type (for manual input);
  • park_process - to process data about parking of some vehicle;
  • db_exec - to process data related to composite events;
  • manual_edit - to show the manual editing window;
  • ev_rec - to record archive after some event occur;
  • start_recognize = [
frame_count = 100;
]
- to start recognition for specified number of frames (in the example - for 100 frames) or in perpetuity.


It is possible to execute database query as the reaction on some event. The next record type should be used:

raw_db_query = [
template = "select '%s' as test";
type = "xml";
result = "test";
exec = [
hello = [
send_msg = [
@type = 500;
];
];
];
];


Parameters in this record are the next:

  • template parameter contains the text of SQL-query in the DB. It could contain pattern '%s', which describes plain vehicle number or detailed information about the vehicle in xml format;
  • type parameter contains information about the format of the vehicle number. In case format is defined as plate - the number of the vehicle will be represented in the plain utf-8 text format. Otherwise, if format is defined as xml - information about number will be represented in xml format and contain detailed information abouut number recognition: recognition channel, time, etc.;
  • result parameter contains name the (names) of columns, which will be used to receive the query data;
  • exec - is the section which can contain possible database reactions on the queries (for example, hello) and what to do in case database gives the reaction (for example, send_msg).


Here is an example of the right record for insertion data to the database: 

raw_db_query = [
template = "insert into q values('%s');select 1 as test";
type = "xml";
result = "test";
exec = [
    ];
];


It is possible to sent information about event to MainConsole system as the reaction on this event. The next record type should be used: 

send_msg = [
  @type = 102;
];


This record contains type parameter, which identifies code of the event to be sent. The next codes can be used:

Event code Event
100 Car in group %s
101 Car let
102 Plate add money
104 Gate action
4 Plate detected
5 Plate lost


Other parameters
  • settings > timeout How much time to save the history. Influences on the parameter car_tries_change_dir. It is necessary for the determination of short-term entry / exit and error detection;
  • all / friends These two nodes contain the rules "for all" and for the groups marked as "their", respectively;
  • Default/ Channel number. These nodes are for signing of policy or for all channels or a channel with the specified number, the numbering from scratch.

acl.plist

acl.plist - is a configuration file, which is designed for the description of setting of Overseer Parking’s remote access, to which it sends the video flow. All the permissions and prohibitions for the IP-addresses and subnets should be written in the file. The policy of "everything is forbidden by default” is working, i.e. if there is no overlap in the permits, it is not allowed. The main role of prohibitions are to specify exceptions for the networks listed in the permits.


Example:

ACL = [
allow = [
work = "192.168.100.0/24";
home = "192.168.73.0/24"; // host
];
deny = [
excl = "192.168.73.128";
];
];


It is also necessary to mark that the following records are considered being equal:

host1 = "192.168.99.1/32";
host2 = "192.168.99.2";

Configuration files in Parking system Конфигурационные файлы в системе Parking Arcivos de configuración del Parking sistema

Retrieved from "https://docs.vitcompany.com/index.php?title=Configuration_files_in_Parking_system&oldid=229"