Door locking and/or opening system, a method for controlling door locking and/or opening, and a door locking and/or opening and documentation system

A door locking/opening system includes multiple doors, each configured with a door ID number, a handle, a lock and an I/O controller, the I/O controller controls the corresponding door; multiple door controllers, each door controller connects the I/O controller of the respective door and controls the corresponding door; multiple sensors, each sensor connects the respective door controller and communicates with the corresponding door; a door controller unit, connected with the respective door controller via a decentralized network and controlling the multiple door controllers; the multiple door controllers are digitally connected and communicating with each other via the decentralized network; each door controller contains its local logbook of own activities and a configuration file of the complete door locking and/or opening system, and each door controller configurated to update and synchronize the configuration file with each other in a rotating cycle based on the door ID numbers in an ascending order, beginning with the lowest door ID number.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to a door locking system, and more particularly to a door locking and/or opening system and a method for controlling door locking and/or opening.

Description of Conventional Art

A conventional door locking and/or opening system normally is using multiple door controllers for multiple doors. In particular, each of the door controllers is connected with an I/O controller of the respective door, and controls the corresponding door via communicating with the respective I/O controller. The individual door controller is connected to and communicating with the corresponding door through its I/O controller, and controls the corresponding door. That is, multiple door controllers in the system only have connection or communication with the corresponding door for the users and administrators, independent from each other.

However, these multiple door controllers have no connection, communication or any control among or between the multiple door controllers. Under the regular mode, since each of the door controllers is separately connected with the I/O controller of the respective door, these door controllers are separated from each other. Thus, there is no controlling message or information exchange among or between the multiple door controllers.

Furthermore, there is no monitoring measure, a logbook of activities or a configuration file of the complete door locking and/or opening system.

Problem to be Solved

As mentioned above, since the door controllers are separated from each other, it is no possible to control other door(s) except its own door. Further, it also is no possible for the door controllers to update and synchronize within the complete system.

SUMMARY OF THE INVENTION

Solution for the Problem

This problem is solved by creating a decentralized network consisted of at least multiple door controllers. Additionally, the door controllers itself also contains a local logbook of own activities and a configuration file of the complete system which are needed for update and synchronization.

The present disclosure provides a door locking and/or opening system, comprising multiple doors, each configured with a door ID number, a handle, a lock and an I/O controller, the I/O controller is configured for controlling the corresponding door; multiple door controllers, each of the door controllers connected with the I/O controller of the respective door and controlling the corresponding door; multiple sensors, each of the sensors connected with the respective door controller and communicating with the corresponding door; a door controller unit, connected with the respective door controller via a decentralized network and controlling the multiple door controllers; the multiple door controllers are further digitally connected and communicating with each other via the decentralized network; each of the door controllers contains its local logbook of own activities and a configuration file of the complete door locking and/or opening system, and each of the door controllers is further configurated to update and synchronize the configuration file with each other in a rotating cycle based on the door ID numbers in an ascending order, beginning with the lowest door ID number.

Each of the door controllers preferably updates and synchronizes the local logbook with a central server according to a first selectable time schedule, and each of the door controllers updates and synchronizes the configuration file with each other according to a second selectable time schedule.

The network communication among the multiple door controllers preferably is encrypted and signed. The door controller unit is configured to maintain the configuration file, to distribute the configuration file to the door controllers, to store the local logbooks and to monitor the actions of each door controller in order to identify malfunctions or manipulations.

The I/O controllers preferably are a network-based I/O controller or a USB-based I/O controller, which is configurated to open or lock the corresponding door.

The system preferably further comprises a door control user panel, the door control user panel communicates with the door controller unit and/or with the network of the individual door controller.

The present disclosure also provides a door locking and/or opening and documentation system, comprising the door locking and/or opening system, wherein a documentation system comprising: a user terminal for second inspections; a frame Grabber to catch X-Ray screens; an X-Ray system for inspection; a webcam; an IP-Cam and a user terminal for screening operator.

The present disclosure provides a method for controlling door locking and/or opening, said method applied in a door locking and/or opening system comprising a first master door and multiple slave doors, each slave door associated with a door ID number, said method comprising steps of: receiving, by the first master door, a request for initiating an opening sequence; determining whether the first master door have an active locking sequence from other master doors; if the first master door has the active locking sequence from other master doors, denying the door-opening request; if the first master door does not have the active locking sequence from other master doors, checking a configuration database for relevant slave doors and status information; inquiring each of the slave door for its status and requesting a lock sequence reservation, in an order from a lowest door ID number to a highest door ID number, until all slave doors contacted confirms without any error message; determining whether the slave door confirms its status and the lock sequence reservation; if one of the slave doors does not confirm its status and the lock sequence reservation, sending cancellation of the lock sequence reservation to the slave door and denying the door-opening request; opening the first master door, and informing all slave doors when the door is closed again.

After the determining step and before the checking step, the method preferably further comprising steps of: informing a second master door that the first master door is requesting for the lock sequence reservation; determining whether the first master door has a lower priority level than the second master door; if the first master door has the higher priority level than the second master door, sending by the second master door a confirmation to the first master door with the higher priority, and continuing by the first master door with the locking sequence reservation until receiving new status information from the second master door; or if the first master door has the lower priority level than the second master door, canceling by the first master door all door locking reservations of the first master door, aborting a reservation sequence initiation by the first master door, and sending a configurable confirmation to the second master door.

Before the receiving step, the method preferably further comprising steps of: detecting, by any one of the master doors or the multiple slave doors, an event where an emergency opening of doors is requested; sending an emergency opening request to the master doors and the slave doors as defined in the database for the requesting event periodically or non-periodically.

Before the receiving step, the method preferably further comprising steps of: detecting, by any one of the master doors or the multiple slave doors, an event where a closing of doors is requested; sending a locking request to the master doors and the slave doors as defined in the database for the requesting event periodically or non-periodically.

When a pre-configured maximum reservation timer is reached, the complete locking sequence preferably is repeated for the configured maximum reservation duration before an error is shown, so as to prevent that some doors are kept locked and prevent restrictions to enter or leave an area.

A locking sequence preferably is transmitted in one frame.

The advantageous effects of the above distinguishing feature to the prior art are illustrated as below. Via the decentralized network the multiple door controllers are digitally connected and communicating with each other. The complete configuration file further enables the door controllers to update and synchronize with each other.

DETAILED DESCRIPTION OF THE INVENTION

The present disclosure will be further described in detail below with reference to the drawings and specific embodiments, in order to better understand the objective, the technical solution and the advantage of the present disclosure. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of the disclosure.

Description of Doors, Door Controllers, I/O Controllers and Status

As shown inFIG. 1, a door locking and/or opening system comprises multiple doors10,20,30,40, multiple door controllers11,21,31,41, multiple sensors, and a door controller unit500. Each of the multiple doors10,20,30,40is configured with a door ID number, a handle, a lock and an I/O controller which is configured for controlling the corresponding door. Each of the door controllers is connected with the I/O controller of the respective door and controlling the corresponding door. Each of the sensors is connected with the respective door controller and communicating with the corresponding door. The door controller unit500is connected with the respective door controller via a decentralized network600and is configurated to control the multiple door controllers.

Furthermore, the multiple door controllers are further digitally connected and communicating with each other via the decentralized network600.

Further, each of the door controllers contains its local logbook of own activities and a configuration file of the complete door locking and/or opening system. In this way, each of the door controllers is configurated to update and synchronize the configuration file with each other in a rotating cycle based on the door ID numbers in an ascending order, beginning with the lowest door ID number.

As an example, according to a selectable time schedule, each of the door controllers periodically updates and synchronizes the local logbook with a central server every ten minutes or every hour or any other selectable time schedule, and each of the door controllers periodically updates and synchronizes the configuration file with each other every ten minutes or every hour or any other selectable time schedule.

A structural description of the system will be present as below.

Door Components

Network Based I/O Controller or USB Based I/O Controller

Network based I/O Controllers may not working encrypted. Thus, if not usable encrypted, they are used only for secondary functions which are restricted to informative purposes but are not used for the sluice function. Security related I/O Adapter will be USB based or embedded to the hardware of the embedded PCs (or door controllers).

Each of doors comprises device for catching the current status of various switches, such like deadbolt switch, Door in Frame switches, various buttons (such as call buttons to open a door, call button for operator, emergency), IR Motion detector, gas sensors (CO, CO2, Temperature, etc.), and other contacts.

The I/O controller will also be used to turn on/off various status lights at a door, such like “locked”, “malfunction”, “cannot open (for whatever reason)”, “open”, “do not enter”, other lights/items which can be switched on and off. The I/O controller will open or lock the door via controlling a deadbolt mover, switching a magnetic door closer/lock, or controlling the engine for moving a door.

Status Display and/or Touchscreen

Status display and/or touchscreen includes extended options for button functions, status messages, other information.

Webcam

Camera on the door controller is configured for monitoring the area around the door. Camera can be turned on only when door movement is needed, permanent or in any other meaning. Images/Video can be sent to user panel and can be stored together with log information (or local logbook).

Microphone

Microphone can be used for communication with persons inside a sluice lock or acoustic level monitoring.

Loudspeaker

Loudspeaker can be used for communication purposes and/or for acoustic warning/message signals, public announcements, etc.

RFID Reader, Barcode Reader and Iris Reader

If not managed or connected otherwise RFID Reader, Barcode reader and Iris Reader will be connected via USB or I/O Adapter. RFID Reader, Barcode reader and/or Iris Reader are Used for additional authentication of authorized persons for the door/sluice.

IP Cameras are directly connected to a network switch and not listed here.

Other devices, not listened here, still can be able to be connected to a door controller.

Door Controller

The door controllers are implemented as embedded PCs, for example. They have two connection side A and side B. The power supply is with an external power supply or power over Ethernet600.

The side A is a network connection to a standard network. This communication will be encrypted/signed as described below. The side B is connection to various door components as described below.

The embedded PCs (or door controllers)11,21,31,41contains the local logbook for own activities, system status and messages received from other door controllers. The embedded PCs contains a configuration file of the complete system in an encrypted database.

Details about the encryption are written below.

When a central server (or door controller unit)500is reachable the local logbook and network activities are copied periodically to the central server and marked in the local database as “transmitted”. They will be deleted on an “oldest entry first to delete” basis when the local storage reaches a pre-defined usage level.

The system configuration database contains a version counter for the current and previous configurations. They will also be stored and only deleted on an “oldest configuration first to delete” basis when the local storage reaches a pre-defined usage level.

The local logbook and configuration databases can be placed on different storage devices at an embedded PCs, in order to expand the storage capabilities.

If requested by a central server, the complete logbook and configuration (file) will be sent to the central server. The version number of the configuration (file) will be used by the door controller-to-controller communication, so as to ensure that all door controllers have the current configuration. If needed the newer configuration (file) will be sent to other controllers.

Function Description of Single Parts

Door controller or Embedded PC is located on each single door for controlling the door with various connections. Also used as communication terminal.

User Panel and Configuration Panel

The user panel and configuration panel can be an extra user panel for controlling/Monitoring the system or the user interface from the central server. In small installations the user panel can contain a central server in the background and not a central server as separate device.

Example of possible functions are: “Monitoring current Status of the doors and System”, “Activating a Camera/Microphone for surveillance etc.”, “Using Loudspeaker for communication/announcements”, “Case by Case override of standard configuration”, and “Override Configuration with marker “Irrevocable for xxx hours” (Timer will run on each door controller independently).

Various user levels will be configured.

Central Server

The central server is in a door/sluice lock system. In this design the central server is optional and not mandatory. If not existing or failing, the central server can be reloaded by the single door controller with the local logbook and the configuration file. The central server can be used for central logbook storage and evaluation of the complete system.

Conventional systems also have a central server which is required for system functionality.

External Configuration Device

External configuration device mostly is an external Notebook or programming device for setting basic configuration on the door controller, central server, user panel. This basic configuration prevents that an end user or unauthorized person can contaminate a system with unauthorized devices. Without the basic configuration a new item will not be accepted by the system. Notebook/programing device contains a software with special options which are not available to others.

Possible settings are, for example, License code, Encryption Base Key, Signature Base Part of the Salt, Advanced User Management (if not disabled by license), Extended Backup/Restore functions (if not disabled by license),

For example, conventional elevators are configured in a similar way.

Network component includes, for example, Network switch for Network Communication.

Cloud connection is connection to external Monitoring/control devices. Cloud connection can be used, for example, for emergency access from an external location with/without override function for the configuration/User interactions.

Description of the Door Locking and/or Opening and Documentation System

As shown inFIG. 2, a door locking and/or opening and documentation system comprises the door locking and/or opening system as described before and a documentation system. The documentation system comprises a User Terminal for Second Inspections700, a frame grabber to catch X-Ray Screens710, an X-Ray system for inspection720, a Webcam730, an IP-Cam740and a User Terminal for Screening Operator770.

The door locking and/or opening and documentation system further comprises a Label printer750or Barcode Reader760.

In an embodiment, all the user terminal700, the frame grabber710, the X-Ray system720, the Webcam730, the IP-Cam740, the user terminal for Screening Operator770, the label printer750and the barcode Reader760are connected through the decentralized network600.

This represents the mostly common way of handling security inspections for Freight, Goods, Persons, Luggage, etc. The incoming freight will be handled throw all inspection steps. The backoffice handles the complete freight processing. This includes managing to forward to the final destination, returning to sender, discussing with sender about additional security inspection, etc. Freight will be X-Rayed to check content for hazards/forbidden content. Documentation of the X-Ray images will be done inside the X-Ray machine or on an external Hard Disk and can be viewed only on the X-Ray machine. The connection with the freight will be done by the time stamp or comments with information about the checked freight. If X-Ray gives no clear result the freight will be inspected by other ways or the second inspection. At the end of the inspection is the result whether the freight can be forwarded or will be returned to the sender.

The basic operation of the X-ray documentation or inspection documentation takes place, for example, as follows. The object identification (freight item, luggage, etc.), which can be an air waybill or another identification feature, is recorded together with the operator information. Only then are images from the X-ray device (or the X-Ray system for inspection720) and optionally from the IP camera740or the webcam730with additional optional information, such as text input with comments or scanned documents, recorded and assigned to this object. This information is saved together with the test result. If a second or additional inspection is necessary, the test process is only saved definitively and unchanged when a final test result is available. This X-ray documentation/inspection documentation is then further used by other areas, e.g. a freight management or access management.

The user terminal for second inspections700is a regular computer System with optional Webcams or connected to optional IP Cameras740and/or other scanners. The screening operator selects the relevant object identification, analyses the X-Ray image from the first inspection and performs the second inspections. These second inspections can optional recorded by Webcam/IP-Cam. Additional documents can be scanned by document scanners. Other optional devices can be connected to the user terminal700. After performed inspection, the inspection result, together with optional comments, will be entered in the user terminal700.

The frame grabber710is connected between the computer inside the X-Ray system and the monitor of the X-Ray System. By this way, the content of the monitor will be copied in live time to the documentation system. Still images and video sequences can be recorded by this way. The frame grabber710is a one-way device and is technically not able to manipulate the monitor signal from the X-Ray system computer. Thus, the image on the monitor(s) will be displayed unchanged. The frame grabber710has no direct user functions. It will be controlled by the software only.

The X-Ray device for security inspection720is used to make the contents of an object visible. These X-ray devices720have one or more monitors. The shown images can be changed with various device-specific image processing/enhancing functions. The screening operator decides how he wants the images to be displayed. Based on the images, the screening operator decides whether an object can be classified as safe or whether it needs second inspections. The images from the monitors are copied via the frame grabbers710and saved for documentation. This method ensures that the images that the screening operator used for his decision are saved in the documentation unchanged.

The user terminal for X-Ray inspections770is a regular Computer System connected to the frame grabbers, the optional Webcams or connected to the optional IP Cameras and/or other scanners. The operator selects the relevant object identification and performs the inspection. This inspection can be optionally recorded by the Webcam/IP-Cam740. Additional documents can be scanned by document scanners. Other optional devices can be connected to the user terminal. Each monitor image, used for a decision by the screening operator can be recorded in the documentation. After performed inspection, the inspection result, together with optional comments, will be entered in the user terminal. The screening operator selects if second inspections are required. The X-Ray inspection and the second inspections are mostly identically performed. The difference is that on the second inspections no X-Ray will be used. The description for the user terminal for X-Ray inspections770is mostly identical to the user terminal for second inspections700.

Description of the Basic Operation

As shown inFIG. 3, a method for controlling door locking and/or opening is applied in a door locking and/or opening system comprising a first master door and multiple slave doors, each slave door associated with a door ID number. The method comprising steps of: receiving110, by the first master door, a request for initiating an opening sequence; determining120whether the first master door have an active locking sequence from other master doors; if the first master door has the active locking sequence from other master doors, denying130the door-opening request; if the first master door does not have the active locking sequence from other master doors, checking140a configuration database for relevant slave doors and status information; inquiring150each of the slave door for its status and requesting a lock sequence reservation, in an order from a lowest door ID number to a highest door ID number, until all slave doors contacted confirms180without any error message; determining160whether the slave door confirms its status and the lock sequence reservation; if one of the slave doors does not confirm its status and the lock sequence reservation, sending170cancellation of the lock sequence reservation to the slave door and denying the door-opening request; opening190the first master door, and informing all slave doors when the door is closed again.

Description of the Collision Operation

As shown inFIG. 4, after the determining step120and before the checking step140, the method further comprising steps of: informing210a second master door that the first master door is requesting for the lock sequence reservation; determining220whether the first master door has a lower priority level than the second master door; if the first master door has the higher priority level than the second master door, sending240by the second master door a confirmation to the first master door with the higher priority, and continuing by the first master door with the locking sequence reservation until receiving new status information from the second master door; or if the first master door has the lower priority level than the second master door, canceling230by the first master door all door locking reservations of the first master door, aborting a reservation sequence initiation270by the first master door, and sending a configurable confirmation to the second master door290.

The confirmation is configurable and can contain separate confirmations. Examples are: (a) Confirmation the higher status to the second door master; (b) Confirmation that the own locking reservation will be canceled; and (c) Confirmation that the own locking reservation has been canceled. These confirmation(s) can be sent in one or more separate messages/confirmations.

Description of the Emergency Opening Operation

Emergency opening and Emergency Closing can be initiated by any door, user panel or optional server. The theory behind is, that an emergency can happen everywhere, every time. Therefore, there is no difference between Master or Slave doors, user panels or optional Servers. An emergency message overrides mostly everything. The only important item is, that the emergency message is correctly encrypted, signed with signature, etc. to have an authentic message.

Priority or first sending to Master Doors coming only in the following situations into effect (after reaching all Master Doors, all other doors, user panels, etc. will be contacted). —Active reservation and one of the doors claims for emergency; —Active reservation and one of the doors has a timeout situation; and—An optional Server or user Panel knows about all active Master Doors and send the emergency order first to all active Master Doors and then to all other doors.

Otherwise, emergency messages will be sent to all doors, etc., depending on the order in the door configuration.

As shown inFIG. 5, before the receiving step110, the method further comprising steps of: detecting, by any one of the master doors or the multiple slave doors, an event where an emergency opening of doors is requested350; sending an emergency opening request to the master doors and the slave doors as defined in the database for the requesting event periodically or non-periodically370.

The step of sending is periodically repeated every xx minutes to keep status alive (see configurations for the definition of xx minutes). Contacted doors will send messages to other doors for cancelation regular door requests.

Description of the Emergency Closing Operation

As shown inFIG. 6, before the receiving step110, the method further comprising steps of: detecting, by any one of the master doors or the multiple slave doors, an event where a closing of doors is requested360; sending a locking request to the master doors and the slave doors as defined in the database for the requesting event periodically or non-periodically380.

The step of sending is periodically repeated every xx minutes to keep status alive. Events, marked as Permanent or with livetime timer do not need to be repeated. Each door will handle such requests independently.

Description of the Door/Sluice Lock Control

General Communication

A standard TCP/IP v4 Package has a payload of 1452 characters (Calculated from a MTU with 1500, deducting TCP, IPv4 and PPP Headers. This calculates 1500−20−20−8=1452). All Network communication for locking sequences are below this limit. Collision Handling is easier if a locking sequence is transmitted in one frame. All other network communication is not restricted to this size. For IPv6 sizes are adjusted accordingly.

Jumbo frames (IP v4) with a selectable payload maximum of 65488 Characters from a maximum selectable MTU with 65536 will only be used with an individual setting when all components can work with Jumbo frames. Jumbo frames will expand the size of Network communication for locking sequences. For IPv6 sizes are adjusted accordingly.

Contact Sequence

The numbers of the door controllers have in an ascending order. A master door contacts the slave doors in ascending order. This speeds up collision detection.

An optional central server is contacted on each decision step in the workflow. A central server can send a collision information to all members when detected.

Communication includes the version of the configuration settings and the current date/time, in order to prevent mixed configuration and that the clocks in the single door controllers are not working synchronously.

Manual override from a user panel is not included in the workflow, but can add if required. Error handling/faulty doors are not included in the workflows.

If a slave door has a lower configuration version as a master door, the slave door will get and receive the updated configuration (or configuration file) by the master door.

If a master door has a lower configuration version as a slave door, the locking sequence will be performed with the configuration version from the master door. This prevents the situation that a configuration update will slow down the complete system. If required, this behavior can be changed to an “Update master door and repeat locking sequence”.

Collision Handling

Collisions can happen in various ways.

When a current collision is handled, additional collisions will be also be managed like the first collision.

When two master doors contacting a slave door at the same time, the TCP/IP Protocol will send one package after the other to the slave door. The first received Network package from the first master door get the priority and the active door lock sequence reservation. All other master doors receive a message about an active door lock sequence reservation.

The second master door gets and receives information about active lock sequence reservation with the ID of the first or primary master door. The first or primary master door gets and receives information about a secondary lock activity. If second master door has a higher Priority level than this first master door, the first master door will cancel its lock sequence reservation and send information message to the second master door when first master door can start its reservation sequence.

When the configured maximum reservation time is reached, the complete locking sequence will be repeated for the configured maximum before an error is shown. This prevents that many collisions will keep some doors locked for a long time and also prevents unneeded/unnecessary restrictions to enter/leave a building/area.

A second master door reaches a slave door with active lock sequence reservation. The second master door gets and receives information about active lock sequence reservation with the ID of the first or primary master.

Both master doors contact each other to verify the locking status and the priority level.

The master door which is selected to cancel the active lock sequence reservation will contact all slave doors and send cancellation. When all cancelations are sent, the working master door starts will send the lock sequence reservation messages.

When the configured maximum reservation time is reached, the complete locking sequence will be repeated for the configured maximum before an error is shown.

Priority action can be from an optional user panel, a central server or a configuration device. If a priority action is valid only for a subset of door controllers, this information is included in the transmitted message. Priority message/order will be sent to all door controller from the door controller unit500.

The door controller with active lock sequence reservation (master doors or slave doors) submits status to the door controller unit500and send also message to door controller with the priority message/order.

Open doors will send an error message to the door controller unit with their status. Depending on priority action, a lock sequence will be completed or aborted.

Description of the Communication Protocol

The single parts of the Sluice lock will be connected with an ethernet connection. Network Protocol will be TCP/IP with IP V4 or IP V6, as needed. The TCP/IP Protocol contains the necessary parts for collision prevention and Bi-directional communication. They will be not described in detail because of being the Prior Art.

The system can be configured to have a cyclic control message sent from each network-connected door controller, the server (or the door controller unit), the panel in a given order and at a given time scale (i.e., time period). Or the system can be a silent system which prevents the unauthorized read out of encrypted network messages.

Operating system based messages will be not suppressed or changed and excluded from the configuration. They are counted as the Prior Art, unless another handling is needed.

Sample Configurations

ConfigurationDescriptionSilentNo cyclic communication from the Control Application.Defective/missing components will be recognizedwhen they do not answer to communication requests.LogbookEvery xx minutes each door controller will send async everystatus message to the central server with the latestxx Min.information about the logbook entries.ConfigurationEvery xx minutes each door controller will sendsync everya status message to the central server asking if thexx Min.current configuration is still valid.Controller toEvery xx minutes the door controllers willcontrollercommunicate to each other to check if thecheckwhole system is valid and completelyeveryfunctional. The direction about who contacts whomxx Min.and who is the failsafe contact will be selected inthe configuration (file).Server/PanelEvery xx minutes the central control server or atouser panel is asking the whole system if everyControllercomponent is working and the whole system iseveryfunctional.xx Min.

Communication details for each sample configuration are described below.

The detailed command structure about the transmitted commands and data packages will be described in details later. The description will contain the following parts.

In the following Tables, the “DOOR_ID” is defined as an ascending ID Number of a door controller and the corresponding Network Address.

Log Transmission

The doors send Log messages with the following protocol.

FieldContentDOOR_IDID of the Door who sends the log message.SEND_IDID of the local Log entry will be used asSend ID.DATEDate (as UTC Date) of the logged activity.TIMETime (as UTC Date) of the logged activity.TIMEZONEWhich Time Zone is used.Possible Entries are for example: UTC;UTC+x; UTC−xTYPEFixed word LOGBOOK indicates transmissionof a Log MessageCONFIG_VERSIONVersion number of the configuration Database.TX_TYPEIndicates if a log transmission will be sent inone transmission or in splitted or separatetransmissions. The Type contains thesplitting counter.Examples:SINGE—Log transmission in a singleTransmissionMULTI xxx—Log transmission in multipleTransmission messages. xxx counts themessage numbers._DEL—This will be added to the Type toindicate Log Entries who will be deleted/stripped after confirmed sending.TX_PARTNumber of the transmission part. Used onlywith multiple transmissions. Valuesignored by single transmission.ACTIVITY1Activity to report.Example of possible entries:ERROR—Error status at the door controllerLOCK_GET—Locking inquiries receivedLOCK_SEND—Locking inquiries sendLOCK_DONE—Locking sequences performedIMAGE—Video image recordedAUDIO—Audio Sequence recordedSTREAM—Video with/without Audio recordedACTIVITY2Dynamic changed Message Part. Dependingon ACTIVITY1.Example for LOCK_GET:No. of Master door, configuration ID,Date/Time of receivingExample for ERROR:Information which sensor/function was notworking correctly.Restoring normal state will be sent as anotherlog message.This part can be additional encrypted.SIGNATUREHash Signature for Authentic Message.

The Server confirms the Log messages with the following protocol.

FieldContentDOOR_IDID of the Door who sends the log message.SEND_ID2ID and Part of the local Log entry will be used as Send ID2.DATEDate (as UTC Date) of the logged activity.TIMETime (as UTC Date) of the logged activity.TIMEZONEWhich Time Zone is used.Possible Entries are for example: UTC; UTC+x; UTC−x.TX_TYPEIndicates if a transmission will be sent in one transmission or insplitted transmissions. The Type contains the splitting counter.Examples:SINGE—Transmission in a single TransmissionMULTI_xxx—Log transmission in multiple Transmissionmessages. xxx counts the message numbers.TX_PARTNumber of the transmission part. Used only with multipletransmissions. Values ignored by single transmission.SIGNATURE_SENTSent Signature. This signature will be calculated by thereceiving server to confirm correct sending. If this value is notequal with the send Signature, the sending door controller willrepeat the message.LOG_IDID of the log entry at the central server.SIGNATURE_SERVERMessage Signature from the Server to the sender.

Configuration Transmission

Sending Configuration

FieldContentDOOR_IDID of the Door who will receive the configuration. TheDoor ID is configurated outside the network and cannot bechanged by configuration messages. To Change the DoorID, it is needed to change the initial door controller Setup.DATEDate (as UTC Date) of the configuration change.TIMETime (as UTC Date) of the configuration change.TX_TYPEIndicates if a transmission will be sent in one transmissionor in splitted transmissions. The Type contains the splittingcounter.Examples:SINGE—Transmission in a single TransmissionMULTI_xxx—Log transmission in multiple Transmissionmessages. xxx counts the message numbers.TX_PARTNumber of the transmission part. Used only with multipletransmissions. Values ignored by single transmission.CONFIG_VERSIONVersion number of the configuration Database.TYPEType of configuration. To save bandwidth, only the relevantparts will be transmitted and not all fields. Example ofpossible entries:DOOR—Door ConfigurationLOCK—Locking settingsEMERGENCY—Emergency settingsSYSTEM_IDSystem ID to contact the correct Door ID with the correctSystem ID.TIMEOUTLOCKINGTimeout for a locking sequence.ENCYPTION_KEYEncryption Key changing. The secret will be sent additionalto confirm changing of the Encryption Key.KEEPALIVETimeframe for sending a message to a central server or tocorresponding slave doors. A Zero setting is used to activatea “silent” mode where the controller is only listing and notsending periodical status messages.PERMANENTTimeframe where a permanent order will be executed if nototherwise specified.PRIORITYPriority Level.SLAVEDOORCLOSEDMaximum Time a slave door can be locked and closed.DOOROPENMaximum Time a door can have the status open. Valid forMaster and slave doors.SENSORxConfiguration information for the sensor with No. x.SENSORx_TOOPENSensor No. x can initiate a door opening.SENSORx_TOCLOSESensor No. x shows that a door is closed.SENSORx_FAILTURESensor No. x.SENSORx_EMERGENCYCLSensor No. x can initiate an emergency Closing.SENSORx_EMERGENCYOPSensor No. x can initiate an emergency Opening.KEEPOPENTime a door must be kept open on Emergency.KEEPCLOSEDTime a door must be kept closed on Emergency.CENTRALSERVERxID and Network Address of central server No. x. Multiplecentral servers can be configured.SERVERTIMEOUTTimeout when a Server is not answering to a Message.SERVERDEADSetting in case of a dead server. This represent special doorconfiguration.LOGTRANSFERTimeframe for sending log entries.CONTROLERCHECKTimeframe for checking sensors if they are workingproperly (if supported by sensor).TIMEOUTMESSAGESTimeout for getting an answer for status messages.CONFIGSYNCTimeframe for checking slave doors.SLAVE_xThis part can be repeated. Configuration details for Slavedoor x.Example of possible details:CLOSED—Must be closedFAIL—Own Door must be locked if Failure reported fromthis doorEMERGENCYCLOSE—Close when this door reports anemergencyEMERGENCYOPEN—OPEN when this door reports anemergencySIGNATUREHash Value to ensure correct message.

The door controller confirms the Configuration messages with the following protocol.

FieldContentDOOR_IDID of the Door who sends the log message.SEND_ID2ID and Part of the local Log entry will be used as Send ID2.DATEDate (as UTC Date) of the configuration change.TIMETime (as UTC Date) of the configuration change.TIMEZONEWhich Time Zone is used.Possible Entries are for example: UTC; UTC+x; UTC−x.TX_TYPEIndicates if a transmission will be sent in one transmission orin splitted transmissions. The Type contains the splittingcounter.Examples:SINGE—Transmission in a single TransmissionMULTI_xxx—Transmission in multiple Transmissionmessages. xxx counts the message numbers.TX_PARTNumber of the transmission part. Used only with multipletransmissions. Values ignored by single transmission.SIGNATURE_RECEIVEDSignature from received configuration. This signature will becalculated by the receiving door controller to confirm correctsending. If this value is not equal with the send Signature, thesending device will repeat the message.LOG_IDID of the log entry. This is to confirm that the message has beenaccepted.SIGNATURE_SENDERMessage Signature from the Receiver to the sender.

This part is only used for the initial door controller Setup. This can be only done by Trained/Certified personnel. Transmission is not limited to Network communication, but also can be done by a special encoded USB device.

FieldContentDEVICE_IDID of the Device who will receive the configuration. The SystemID is calculated on Hardware characteristics and identify theHardware of a controller. It can be, for example, the CPU ID,Mainboard ID, Network Adapter ID or a randomized ID, createdby the Software for individual identification.DATEDate (as UTC Date) of the Initial Setup.TIMETime (as UTC Date) of the Initial Setup.TX_TYPEIndicates if a transmission will be sent in one transmission or insplitted transmissions. The Type contains the splitting counter.Examples:SINGE—Transmission in a single TransmissionMULTI_xxx—Log transmission in multiple Transmissionmessages. xxx counts the message numbers.TX_PARTNumber of the transmission part. Used only with multipletransmissions. Values ignored by single transmission.CONFIG_VERSIONInternal Config Version of Initial door controller Setup.DOOR_IDID Number of the Door and the Network Address of the Door.SYSTEM_IDID of the System where the door controller is used.ENCYPTION_KEYOwn encryption Key for creating signatures. Can be changed bycentral configuration if needed.SECRETSecret Key. Required to change initial Door setup after firstconfiguration. If not known, the door controller must be set upfrom the earliest beginning.SIGNATUREHash Value to ensure correct message.

Regular Communication Between the Single Parts

FieldContentSENDER_DOOR_IDID of the Door who will receive the configuration. The Door IDis configurated outside the network and cannot be changed byconfiguration messages. To Change the Door ID, it is needed tochange the initial door controller Setup.RECEIVER_DOOR_IDDouble Confirmation who is the receiver of the Message.DATEDate (as UTC Date) of the Communication.TIMETime (as UTC Date) of the Communication.TX TYPEIndicates if a transmission will be sent in one transmission or insplitted transmissions. The Type contains the splitting counter.Examples:SINGE—Transmission in a single TransmissionMULTI_xxx—Log transmission in multiple Transmissionmessages. xxx counts the message numbers.TX_PARTNumber of the transmission part. Used only with multipletransmissions. Values ignored by single transmission.CONFIG_VERSIONVersion number of the configuration Database.TYPEType of Communication. To save bandwidth, only the relevantparts will be transmitted and not all fields.Example of possible entries:ACTION—Locking Action MessagesFAILURE—Failure MessagesEMC—Emergency MessagesALIVE—Alive MessagesTIMESYNC—Additional Time Synchronization MessagePARAMETER_xThis part can be repeated. These parameters contain the specificcommands, needed for the selected TYPE.SIGNATUREHash Value to ensure correct message.

The door controller confirms the regular messages with the following protocol.

FieldContentDOOR_IDID of the Door who sends the log message.SEND_ID2ID and Part of the local Log entry will be used as Send ID2.DATEDate (as UTC Date) of the Communication.TIMETime (as UTC Date) of the Communication.TIMEZONEWhich Time Zone is used.Possible Entries are for example: UTC; UTC+x; UTC−x.TX_TYPEIndicates if a transmission will be sent in one transmission orin splitted transmissions. The Type contains the splittingcounter.Examples:SINGE—Transmission in a single TransmissionMULTI_xxx—Transmission in multiple Transmissionmessages. xxx counts the message numbers.TX_PARTNumber of the transmission part. Used only with multipletransmissions. Values ignored by single transmission.PARAMETER_xThis part can be repeated. These parameters contain thespecific answers if needed for the selected TYPE.SIGNATURE_RECEIVEDSignature from received configuration. This signature will becalculated by the receiving door controller to confirm correctsending. If this value is not equal with the send Signature, thesending device will repeat the message.LOG_IDID of the log entry. This is to confirm that the message has beenaccepted.SIGNATURE_SENDERMessage Signature from the Receiver to the sender.

Database Configuration

The system will have various databases as described below. All databases are encrypted and secured with signatures.

Log Database

Log Database contains logbook of each activity of a single door controller, the central server, the user panel, etc. The logbook can be used to playback the activity of all doors and users. If User ID can be tracked by RFID, Barcode, etc., the movement of an individual object can be tracked and recovered.

Optional entries can be used, but must not. They are reserved for further usage. Local Log Database and Central Log Database have identical structure, in order for better maintenance of the software.

FieldDescriptionEntry No.Record No./Index.DateDate of record in local time.TimeTime of record in local time.Time zoneTime zone information for recalculation in UTC.Date UTCDate of record in UTC Time. Used to have a collision free date if thetime is around midnight to prevent questionable dates. (Optionalentry).Time UTCTime of record in UTC Time (Optional entry).Door IDID of the Door who has created the Log entry.Door Log IDLocal Log ID from the Door. This entry is mostly used to performadditional tests when resending log entries from the doors to thecentral server.ConfigurationVersion ID of the used configuration.VersionSystem IDSystem ID of the Installation. This Field makes it possible to have acentral log server for several installations. Each installation can beidentified by this Field. The salt for the Signatures is depending on theSystem ID. Therefore, different Salts for different installations can beused in one database.Slave DoorDoor which has been contacted. Own door activities will have the ownDoor ID in this field. If no Slave Door was involved, this field willcontain a dummy entry for Signature Calculation.ActivityActivity details.Possible details are for example:Status request from a doorReservation of Sluice procedureReceive status request from a doorSend error status to a doorSend error status to ServerReceive error status from a doorReceive Reservation request from a doorReceive of configurationRequest to send Logbook complete/only newRequest to send Configuration (current/all histories)Override from Server or User PanelIrrevocable order from Server or User PanelCommunication request/established communicationCamera activationPressed buttonsDoor Status of each individual connected sensorDoor MovementsSend/receive Reservation cancellation for Sluice procedureSignature 1Signature for the fields until this field. This signature will never bechanged. Signature 2 is changeable as described at Signature 2.Transmitted toID of the central server who has received the logbook entries.ServerTicket No. fromTicket Number is the record number from the central server underServerwhich this log entry is recorded at the central server.Transmission DateDate when the Log entry has been transmitted to the central server.This Date is when the ticket from the server has been received. If UTCfield is used, this Date is UTC Date, otherwise local date.Transmission TimeTime when the Log entry has been transmitted to the central server.This Time is when the ticket from the server has been received. If UTCfield is used, this Time is UTC Time, otherwise local Time.Signature 2Signature of the complete Fields including Signature 1. This signaturewill be changed when the Log Record has been transmitted to a centralserver.Record fileOPTIONAL: Storage of the whole logbook record as additionalencrypted file. Only recommended in environments with extendedsecurity requirements.

Configuration Database

Configuration Database contains Configuration of the sluice function, encryption details, failback procedures, door ID's, etc. Each complete configuration (or configuration file) has a version number and signature. This enables that the whole system can check itself whether the configuration is identical or various door controllers have various configuration versions.

This structure is mostly identical to the configuration transmission.

FieldContentDOOR_IDID of the Door where the following configuration belongsto. The Door ID is configurated outside the network andcannot be changed by configuration messages. To changethe Door ID, it is needed to change the initial door controllerSetup.DATEDate (as UTC Date) of the record.TIMETime (as UTC Date) of the record.CONFIG_VERSIONVersion number of the configuration Database.TYPEType of configuration settings. A door configurationcontains many settings. To sort them into groups they aregrouped into different types.Example of possible entries:DOOR—Door ConfigurationLOCK—Locking settingsEMERGENCY—Emergency settingsSYSTEM_IDSystem ID to contact the correct Door ID with the correctSystem ID.TIMEOUTLOCKINGTimeout for a locking sequence.ENCYPTION_KEYEncryption Key changing. The secret will be sent additionalto confirm changing of the Encryption Key.KEEPALIVETimeframe for sending a message to a central server or tocorresponding slave doors. A Zero setting is used to activatea “silent” mode where the controller is only listing and notsending periodical status messages.PERMANENTTimeframe where a permanent order will be executed if nototherwise specified.PRIORITYPriority Level.SLAVEDOORCLOSEDMaximum Time a slave door can be locked and closed.DOOROPENMaximum Time a door can have the status open. Valid forMaster and slave doors.SENSORxConfiguration information for the sensor with No. x.SENSORx_TOOPENSensor No. x can initiate a door opening.SENSORx_TOCLOSESensor No. x shows that a door is closed.SENSORx_FAILTURESensor No. x.SENSORx_EMERGENCYCLSensor No. x can initiate an emergency Closing.SENSORx_EMERGENCYOPSensor No. x can initiate an emergency Opening.KEEPOPENTime a door must be kept open on Emergency.KEEPCLOSEDTime a door must be kept closed on Emergency.CENTRALSERVERxID and Network Address of central server No. x. Multiplecentral servers can be configured.SERVERTIMEOUTTimeout when a Server is not answering to a Message.SERVERDEADSetting in case of a dead server. This represent special doorconfiguration.LOGTRANSFERTimeframe for sending log entries.CONTROLERCHECKTimeframe for checking sensors if they are workingproperly (if supported by sensor).TIMEOUTMESSAGESTimeout for getting an answer for status messages.CONFIGSYNCTimeframe for checking slave doors.SLAVE_xThis part can be repeated. Configuration details for Slavedoor x.Example of possible details:CLOSED—Must be closedFAIL—Own Door must be locked if Failure reported fromthis doorEMERGENCYCLOSE—Close when this door reports anemergencyEMERGENCYOPEN—OPEN when this door reports anemergencySIGNATUREHash Value to ensure correct storage.

System Database

This System database contains the individual system information. And System database individualizes the whole system. Unconfigured devices without this System database will be ignored by the complete system and recorded in the logbook as detected intruders. External configuration devices need to have a copy of the system database in order to be recognized.

This structure is mostly identical to the configuration transmission.

FieldContentSYSTEM_IDSystem ID from the whole installation.DATEDate (as UTC Date) of the record.TIMETime (as UTC Date) of the record.CONFIG_VERSIONInternal Config Version of Initial doorcontroller Setup.ENCYPTION KEYEncryption key of the whole system.DOOR_IDID Number of the Door and the NetworkAddress of the DoorDEVICE_IDDevice ID from a Door ID. Only stored on acentral server or external. Not stored on otherdevices. Required only to changeinitial values of a Door controller.SECRETSecret Key. Required to change initial Doorsetup after first configuration. If not known,the door controller must be set upfrom the earliest beginning. Only stored on acentral server or external. Not stored onother devices. Required only to changeinitial values of a Door controller.SIGNATUREHash Value to ensure correct record storage.

Encrypted/Secured Storage and Transmission of Configuration File, System Communication and Logbook

Encryption, signature, etc. will be available as selectable items. The End-user can select which parts of the encryption will be activated and used. An option to restrict the selection with licensing options will also be possible.

Additional to the encryption, the encrypted message/information can be stored/transmitted, for example via RGB color pattern (where the question is how to read the single pixels of the pattern and how the binary information has been transformed to color RGB information) or via Pseudo Base64 string (where the conversation table such as abcdefg . . . has been modified to a different table such as bcDefG . . . ).

Without the information on how the information has been transformed, the content cannot be decrypted.

While the disclosure has been described by way of example and in terms of exemplary embodiment, it is to be understood that the disclosures is not limited thereto. It is to be understood that the above-described embodiments are merely illustrative and not restrictive. To the contrary, it is intended to lamp shade various modifications and similar arrangements (as would be apparent to those skilled in the art).

It will be readily understood by those skilled in the art that the above various preferred embodiments can be freely combined and superimposed without conflict. Various obvious or equivalent modifications or alterations to the above-described details will be included in the scope of the claims of the present disclosure without departing from the basic principles of the application. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.