Background
As in most universities, for engineering students to complete their undergraduate degree, they must engage in a design project, usually during their last year of undergraduate studies. Such design project is based on their engineering knowledge and skills that the students had acquired over their college career and is supervised by a faculty member. The topic of the design project are usually open, granted that the students have suffice prerequisite knowledge and experiences along with the availability of faculty advisors, or the design project can be selected from a pool of design projects given by the faculty, at certain universities the design projects are assigned. At Stony Brook, engineering students can either pick from a pool of projects or come up with their own if they are able to find a faculty member willing to supervise it.
The origination of this project came from the interaction and fusion of ideas between the engineers of this project and Eric Johnfelt and Robert Wlodarczyk, whom both work with the State University of New York at Stony Brook, SINC Site, the primary computing facilities for the campus, when Mr. Johnfelt made it known that he was not satisfied with the existing security systems that are installed on some of the remote SINC Site areas. He was looking for a security system that can be more scalable, robust, reliable and built on the Windows CE platform, which can also provide a centralized control over existing networks. Based on his research, there are no systems out in the market that has all of these features. So this marks the beginning of NESSg1.
What is NESSg1 physically?
  |
NESSg1 is simply a Single Board Computer (SBC), with a LCD display, numeric keypad, magnetic card reader, door latch, siren, and break-in sensor all as separate components connected to the SBC. SBC- A "motherboard" with all necessary integrated peripherals and devices, such as NIC, video, sound, so that the board itself is all that is needed to operate as a computer. |
What is NESSg1 suppose to do?
Ideally, a separate NESSg1 system will be placed in each area (area and room will be used interchangeably) to be secure. For example, if there are several SINC site, each SINC site will have its own NESSg1 unit. Each NESSg1 unit will have its own unique ID associated with the room that it's securing, such ID can simply be an integer number. There will be a central database server, running Microsoft SQL 2000, which will contain a database consisting of all the users who are authorized to have access to each individual NESSg1 secured room.
A typical user attempting to gain access to a room would swipe their student identification card and enter a matching PIN number. At that point, the NESSg1 system that they are interacting with for that particular room would check its own local database, which is running Microsoft SQL 2000 for WinCE to see if the user is present and if he/she is authorized to access the room at that particular time, among other conditions which is to be defined by the NESSg1 engineers and security administrator(s). If the user is present in the local database, and the user met all conditions defined by the NESSg1 engineers and security administrator(s), then the NESSg1 system securing that room will disarm the siren and break-in sensor and unlocks the door latch allowing entrance.
If the user is not present in the local database, the NESSg1 securing that room will query the central database server via the Ethernet network to see if the user is present in the central database server and should be allowed access to that particular room (perhaps this user is new and is his/her first time trying to access the room and who's account has just been added to the central database). If that is the case, the user's database record will be copied from the central database server to the local database in the NESSg1 system securing that particular room then NESSg1 will disarm the siren and break-in sensor and unlocks the door latch, and entrance can be made, provided that all other conditions defined by the NESSg1 engineers and security administrator(s) are met. For example, a special flag that locks the user's account temporary is not set to true, and such flag can be set to true because the user was caught bringing food into the lab previously.
An initially installed NESSg1 in a particular room will have an empty local database, and normal operation will take place to fill its local database. In other words, initially all users will be checked with the local database, which is empty, and then their record will be retrieved from the central database to the local database and over time, the local database will have records of the most frequent users who access the room.
If the user can't be found in neither the local or central database or if the record in the central and/or local database indicates that the user should not have access to the room (for any reason, such as he/she is not authorized to access the room at that particular time, or his/her account has temporary been locked), he/she is simply denied access and asked to contact the security administrator. For any other circumstances, where the siren is not disarm, and the door opens, which will set off a break-in sensor, then the siren will go off, and NESSg1 will log such event to the central database server.
The purpose of copying the record to the local database, and using it as a cache, is to avoid unnecessary network traffic when the same user attempts to enter the room in the future, and also for fault tolerance. Let's just say if the network has gone down, the local database can still let most users have access to that particular room.
If the user's account has been deleted, or some alteration is made, the central database will synchronize with the NESSg1 system(s) that contains a record of that user. The central database will also be capable of being controlled remotely via laptop or other mobile devices to add new users, delete users or any other alteration to the central database. Hence, theoretically, each room secured by a NESSg1 unit can be control indirectly.
Documents on NESSg1: