Student: Rajeshree Varangaonkar
Faculty Advisors: John Baras and Mark Austin.
Date: September 2002 -- May 2003.

TABLE OF CONTENTS

1. Project Description
   Purpose : Setup problem.
   Topics : Scope and objectives; system framework and boundary.

2. Goals, Scenarios, and Use Cases
   Purpose : Create system requirements.
   Topics : Goals and scenarios; initial use cases and activity diagrams.

3. Generation of Requirements from Use Cases
   Purpose : Create system requirements.
   Topics : High-level requirements; synthesis of detailed-requirements; use-case/task interaction matrices; traceability.

4. Simplified Models of System Behavior and System Structure
   Purpose : Create simplified models of behavior and structure.
   Topics : Models of system behavior; models of system structure.

5. High-Level System Design
   Purpose : Create models of the high-level system design.
   Topics : Create mappings from high-level behavior onto elements of the system structure; requirements traceability matrix.

6. Generation of Specifications
   Purpose : Create pathway from low-level requirements to quantitative specifications.
   Topics : Specifications.

7. Tradeoff Analysis
   Purpose : Create framework for trade-off analysis for selection of components in a small subsystem.
   Topics : Measures of effectiveness; problem formulation; characteristics of queue models; analysis in Excel; trade-off analysis results.

8. System Test, Verification and Validation
   Purpose : Develop procedures of system test, verification and validation.
   Topics : Test plan.

9. References and Web Resources
   

Scope and Objectives

1. What are the purposes of the engineering system? Who will use it? And where?

   In the wake of recent attacks on buildings, security has become a major concern. The objective of the project is to conceptualize, design, and develop an intelligent sensor network for the security of any building. The link below gives an idea of its growing demand in the market

   http://www.fcw.com/fcw/articles/2002/0429/news-smart-04-29-02.asp

   A brief concept is described below: The idea is to use sensors to track any untoward incident occurring inside and outside the building with a computer interface to detect any discrepancy recorded in the sensor measurements. The measurements will have to be sorted out to provide meaningful information. For this primarily required to classify data such that a sensor does not duplicate, contradict or give false information regarding an event or a measurement recorded by another sensor. A database must be provided to facilitate the interpretation of data provided by the sensors e.g. the acceptable signals of normal operation, signal values above the threat threshold. Next in line would be to consider integrating these sensors by a network to allow the information to be communicated to a central computer that will process data and generate alarms. The alarm system will also require a detailed analysis, its various aspects being local alert, remote alert, bad signals, emergency, sensor malfunctioning to cite some of its requirements.

2. What factors are likely to influence the economics of product development, choice of technology etc...

3. Some of the factors influencing the choice of technology are enumerated below:

   • Reliability,
   • Speed of the system,
   • Tamper proof.

4. Are their significant risks in development?

   Budget changes is a risk to be guarded against. Since the design is state of the art a shortage of funds can impair further development if costs have not been checked in the earlier stage of development

5. What are the roles and responsibilities of the main groups of people working on the system development (e.g., architects, engineers)?

   The project involves developing a smart sensor networks for smart buildings. The technical area splits in the following main divisions

   • The network design; involves assigning communication protocols, on-the-fly bandwidth allocation and all issues relating to communication management
   • The sensor network design; involves the type of sensors to be chosen, their ranges and specifications etc.
   • The building design; the plan of the building, the construction etc.

The main topic presented below will be a part of the main system described above. It basically deals with the access at the entrance to the building. The idea is to prevent unauthorized access to the building and also to keep track of the people within the building. To ensure a secure access system a card reader with an integrated scanner will compare the biometric obtained from the system with the one obtained from the employee. This will be used to identify the card bearer.

System Framework and Boundary

Insert description .....

Figure 1. Schematic of System Framework and Boundary

Goals and Scenarios

Goal 1. System must allow user to easily program the settings

Scenario 1.1. -- Authorized personnel uses the keypad to enter configuration data and the system prompts the personnel with display messages.

Goal 2. System allows easy enrollment of employees

• Scenario 2.1. -- Authorized personnel swipes card.
• Scenario 2.2. -- Employee to be enrolled then inserts his card in the slot of the card reader and the number on card is captured.
• Scenario 2.3. -- Employee will then scan fingerprint which will be captured and stored as a template in database as well as on the card. Employee removes his card.
• Scenario 2.4. -- Authorized personnel then swipes his own card again and exits the enrollment mode.

Goal 3. Authorized Personnel must be allowed to gain access to the protected area

• Scenario 3.1. -- Authorized person enters the protected area.
• Scenario 3.2. -- Authorized person swipes identification card, and enters access code. The identification number access code and biometric obtained are matched with the database of the card reader. If a match is found the person is allowed access to the building

Goal 4. System must not allow unauthorized person in

• Scenario 4.1. -- Unauthorized person enters the protected area. If identity card is found to be fake Unauthorized Person cannot access system. An alarm should be generated if card does not belong to company.

Goal 5. System must track movement within building

• Scenario 5.1. -- Authorized person enters the protected area. .
• Scenario 5.2. -- Authorized Person wears an identification tag all the time in the building. NCMS tracks the tag over the network using sensor information and keeps track of the individual.

Goal 6. A Visitor should be allowed to enter the protected area

• Scenario 6.1. -- When a visitor arrives at the main gate a confirmation will be made with the authorized employee to be seen regarding the identity of the visitor and the purpose of visit.
• Scenario 6.2. -- Information regarding the visitor is stored in the database along with the details of the employee to be met.
• Scenario 6.3. -- Visitor will be assigned a temporary tag and will be enrolled by an authorized individual to capture biometric.
• Scenario 6.4. -- When visitor leaves he is required to surrender the tag

Goal 7. In case of unauthorized access system blocks exits

• Scenario 7.1. -- Unauthorized person enters the protected area and clears security checks at main gate with fake identity card
• Scenario 7.2. -- Biometric check of individual will fail to match with database
• Scenario 7.3. -- Alarms are generated, all exits are closed and security is alerted.

• Scenario 8.1. -- Fault occurs in system, faulty component generates alarm. Maintenance staff is alerted.
• Scenario 8.2. -- Maintenance staff will set the reader in maintenance mode and the door controlled will remain locked.

Actors

1.	Authorized Personnel
2.	Unauthorized Personnel
3.	Card reader
4.	Control Room Staff
5.	Visitor
6.	Security

Use Case Diagram

Figure 2. Use Case Diagram

Use Case 1. Authorized Access

• Pre-conditions: The system is operational with security personnel in place and the network functioning.
  Actors: Authorized Personnel, Card Reader, Security.
  Flow Of Events:
  
  1. The employee reaches the access door of the building and swipes identification card.
  2. The card is compared for a match in the database of the reader.
  3. The reader confirms that the card belongs to the company
  4. The employee is requested to enter access code
  5. The access code is entered and verified
  6. The access code is entered and verified
  7. The scanner then scans the biometric from the employee and compares it with the one on the template and one in its own database.
  8. A match is found and the employee is cleared
  Alternative Flow of Events:
  1. A visitor arrives at gate. He/She is authorized but does not have the valid identity.
  2. Security contacts employee visitor intends to meet and verifies information about the visitor.
  3. Visitor is assigned a temporary tag and temporary access code and allowed to proceed.
  4. The visitor will be enrolled by the authority with a special code for visitor record.
  5. When the visitor is on the premises a record will be kept as to his whereabouts in the building.
  6. When visitor leaves the premises he/she must surrender the tag and the temporary access code will be destroyed in the database, which will prevent misuse of access code. The record of the biometric and the information of visitor will however be retained for future need.
  Post-conditions: Visitor is allowed inside the protected area.

Use Case 2. Un Authorized Access

• Pre-conditions: The system is operational with security personnel in place and the network functioning.
  Actors: Unauthorized Personnel, NCMS, Security.
  Flow Of Events:
  1. An unauthorized employee arrives at gate, with fake identity.
  2. The card is swiped and he door odes not open as it doesn't recognize the card.
  3. An alarm is generated if the card is not recognized as belonging to the organization
  Post-conditions: Unauthorized employee is not allowed inside the protected area.

Use Case 3. Tracking

• Pre-conditions: The system is operational with security personnel in place and the network functioning.
  Actors: Authorized Personnel, NCMS, Security.
  Flow of Events:
  1. Authorized person arrives at the access door swipes card and inputs the access code.
  2. After person has cleared all security checks and admitted inside the building, he/she is assigned a tag.
  3. This tag is monitored by sensors and the tracking information is conveyed to the NCMS system via the network.
  Post-conditions: Position of every person within the building is tracked.

Use Case 4. Alarm Generation

• Pre-conditions: The system is operational with security personnel in place and the network functioning.
  Actors: Unauthorized Personnel, NCMS, Security.
  Flow of Events:
  1. An unauthorized employee arrives at door with a stolen card.
  2. The biometric is compared for a match in the database of the reader as well as with the template on the card. A match is not found and alarms are generated to alert the control room staff as well as the security at the gate The door is locked by the reader,
  3. The system is placed on alert by the NCMS which causes all exits to be closed throughout the building
  Post-conditions: Unauthorized person is not allowed to leave and is apprehended.

Use Case 5. Maintenance

• Pre-conditions: System is functioning in normal mode.
  Actors: Control Room staff, NCMS
  Flow of Events:
  1. A hardware (e.g. a sensor) component on the system goes into faulty mode
  2. A fault alarm is generated by the component
  3. The NCMS records the event ensures the backup is in place and switches master level status to the redundant system.
  4. NCMS alerts required staff about the fault and the component is attended to.
  5. When the fault is cleared, status of the component is restored to normal from faulty mode and master level status is reassigned to the component system.
  Post-condition: Fault has been cleared and system is functioning normally

Activity Diagram

Use Cases 1, 2, 3, 4 can be combined into one single activity diagram

Figure 3. Combined Activity Diagram for Use Case 1 through 4

Figure 4. Activity Diagram for Use Case 5

Activity Diagram #2

Figure 5. image010.jpg

Now that the baseline textual use cases and the scenarios are in place, we can now generate the requirements for the security identification system. Requirements are derived from various goals and scenarios, use cases so it is important to trace back the source of requirement.

High-Level Requirements

The high-level requirements for system access control are as follows:

Preliminary Assessment

These requirements are ambiguous and are not properly quantified. This is typically the case at the beginning of design and these requirements are typically expressed with words like should, may etc. So the requirements are basically expressed in English without any proper quantification. We break down these requirements to arrive at requirements mapping to the system, subcomponent and component levels. This is a top down approach. These lower level requirements should trace up to one or more higher level requirements. If it doesn't then it probably is not required. If a higher level requirement doesn't break down to a lower level requirement the requirement is nto being satisfied by the system design being considered. Similarly every requirement should trace to a component in the system.

Synthesis of Detailed Requirements

The requirements synthesis is as follows:

Use-Case/Task Interaction Matrices

Insert material from ENSE 621 .....

Traceability

Insert material from ENSE 621 .....

System Structure

Figure 6. Class hierarchy for System Structure

Statechart Diagram

Figure 7. Statechart for Intruder Behavior

Sequence Diagram

Figure 8. Sequence diagram for Swiping an Access Card and Verifying Access

Total verification < 5 second t < 15 secs

We create the system design by mapping chunks of system behavior onto objects in the system structure.

Mapping between System behavior and System structure

Figure 9. Sequence diagram for Swiping an Access Card and Verifying Access

Figure 10. System Structure

Functions in Figure 9 are mapped to classes in the system structure.

Logical Design Of System

This section discusses the logical design of the Intelligent Network System. This logical design does not make any commitment to any kind of technology. Based on this logical design the physical design of the system is done.

Figure 11. High-Level Schematic for Logical Design

Requirements Traceability Matrix

In this section we transform the low-level requirements into qualitative specifications that can: (1) be evaluated via performance analysis, and (2) act as constraints in trade-off analysis.

Specifications

An intelligent sensor network for the protection of a building serves to protect the building from any untoward incident. It should thwart any possible threat to the system. Though the potential threats to such a system are numerous only one type of threat (Unauthorized access) has been considered here.

Measures of Effectiveness

The "measures of effectiveness" for such a system should include the system reliability and accuracy. It should also include the level of redundancy incorporated in the system to reduce potential danger due to a sub-system outage or malfunctioning. Since protection of system is the chief concern the cost analysis takes a lower priority in the analysis.

Performance Characteristics

• Minimizing the Cost: The system should provide maximum benefits such as tamper proof environment resistant, built in back up power supplies etc at minimum cost.

• Maximizing the reliability would concentrate on features of the system such as tamper proof, environment resistance. It would also depend on the redundancy built into the system

• Minimizing the time required to clear a single employee: This is a direct measure of the speed of the system. If the system takes considerable time in clearing one employee the idea might not be feasible

Decision Variables

• Time taken by system look up: The time taken by the system is the service rate of the readers. This is a choice between two manufacturers

• Number of card readers: This variable decided the cost, system reliability and also the time taken to clear an employee. If the number of readers is more than the queue lengths are smaller but the reliability is lower and the cost is higher.

• Number of engineers: This variable decides the cost of the system

Problem Formulation

1. Minimize the Cost

   The cost is decided by:

   • Cost of The reader and scanner Choice between 2 makes (satisfying requirements) X1, X2 (Boolean variables giving choice between the two makes) Cost of backup power supply: Redundant supply available choices two makes Y1 and Y2 (Boolean variables giving choice between the two makes)
   • Cost of software for networking capabilities; K1&K2(Boolean variables giving choice between the two makes)
   • Cost of engineers developing database
   W = Number of engineers deployed. Assume that engineers are paid @ 25$/hour Number of hours= 4

       Total Cost = R * (X1 D1 + X2 D2) + (Y1*DB1+Y2*DB2+K1*X1+K2*X2 + 25*4*W
   

   where

       R = number of card Readers 
   

2. Maximize Reliability

   Reliability of card reader = Rcr Reliability of scanner= Rscan Reliability of card= Rcard Reliability of tamper proof covering= Rtap Reliability on adverse environmental conditions= Renv

3. Minimize Time

   Metric 1 – Cost(minimize) Total Cost =R* (X1D1+X2D2) + (Y1*$1+Y2*$2) +K1*X1+K2*X2+ 25$* 4* W where R= number of card Readers;

   Metric 2– Reliability (maximize) Reliability= (Rcard)^( R*X)* (Rbattery)^(R*Yj)* (Rcomm)^(R*Kj) ?reliability is the product of independent component reliabilities. With Xi =Boolean variable giving manufacturer; i= 1,2 With Yj =Boolean variable giving manufacturer; j= 1,2 With Ki =Boolean variable giving manufacturer; i= 1,2

   Metric 3- Minimize Time to clear one employee 0.5*(ca^2+cp^2) *(rho)^ ((sqrt (2*R+2)-1)) /(mu*(1-(rho))*R)< N1 Time

   Hour	# of people	Arrival Rate
   600-700	75	0.020833333
   700-800	80	0.022222222
   800-900	64	0.017777778
   900-100	14	0.003888889
   1100-1200	15	0.004166667
   1200-1300	48	0.013333333
   1300-1400	65	0.018055556
   1400-1500	45	0.0125
   1500-1600	10	0.002777778
   1600-1700	20	0.005555556
   1700-1800	70	0.019444444
   1800-1900	60	0.016666667
   1900-2000	34	0.009444444
   Mean = 46.1538462 Stdev = 25.09929		0.012820513
   		0.006972025

   Mean arrival rate= 0.012820513

The activity of the building at different times of the day is summed up in the table below:

Figure 12. Traffic Activity in Building throughout the Day.

Depending on the periods of the day there are times when the building is busy and others when it is not. We need to decide the average arrival rate to help us determine the number of readers to be installed to limit the waiting times for people.

Two major factors in the system:

• Cost of providing service: cannot afford many idle servers.
• Cost of employee waiting time: employee will have to wait in longer queues
• Tradeoff between these 2 factors

Figure 13. Tradeoff in Cost of Service versus Cost of Waiting

Characteristics of Queue Models

Key characteristics of the queue models are as follows:

• Calling Population

  Infinite population: leads to simpler model,
  Finite population: arrival rate is affected by the number of employees already in the system.

• System Capacity

  The number of employees that can be in the queue or under service. An infinite capacity means no customer will exit prematurely.

• Arrival Process

  For infinite population, arrival process is defined by the inter-arrival times of successive customers. Arrivals can be scheduled or at random times.

• Queue Behavior

  Queue behavior describes how the customer behaves while in the queue waiting

      ·balking - leave when they see the line is too long
      ·renege - leave after being in the queue for too long
      ·jockey - move from one queue to another 
  

• Queue Discipline

      ·FIFO - first in first out (most common)
      ·FILO - first in last out (stack)
      ·SIRO - service in random order
      ·SPT  - shortest processing time first
      ·PR   - service based on priority
  

• Service Times

      ·random --  mainly modeled by using exponential distribution or truncated normal 
                  distribution (truncate at 0).
      ·Constant
  

  Service mechanisms describe how the servers are configured.

      ·Parallel - multiple servers are operating and take customer in from the same 
                  queue. 
      ·Serial   - customers have to go through a series of servers before completion of 
                  service
  

  Combinations of parallel and serial are possible.

In mathematical terms, the queue characteristics are:

    ·l      Customer arrival rate (in customers per time unit)
    ·m      Service rate of one server (in service/transaction per time unit)
            Performance metrics
    ·r      Average utilization factor, percentage the server is busy.
    ·Lq     Average length of queue
    ·L      Average number of customers in the system
    ·Wq     Average waiting time in queue
    ·W      Average time spent in the system
    ·Pn     Probability of n employees in the system

Utilization (fraction of time server is busy)= r=arrival rate/service rate

We assume that our system is G/G/k where G stands for a general distribution at arrival and Departure and k stands for number of servers.

G/G/k Assumptions

General inter-arrival time distribution with mean m and std. dev. = sa General service time distribution with mean m and std. dev. = sp Multiple servers (k) First-come-first-served (FCFS) Examples of distributions:

1.	Normal
2.	Weibull
3.	LogNormal
4.	Gamma

Coefficient of Variation C = stddev/mean

The average waiting times (approximate) are given by:

Waiting time increase with square of arrival or service time variation Decrease as the inverse of the number of server-service rate is defined as time taIn our case:ken for server to complete one transaction= 1sec in our case In our case the service rates provided by 2 manufacturers are 1 and 2.5 secs. If we assume that the total time taken to clear one employee is 15 secs including employee fumbling and blundering then it takes 15 secs for Manufacturer 1 to clear an employee and 17.5 seconds for manufacturer 2. In our case the utilization factor is 0.019

Solution Procedure

To find the optimal point in the design space, will be a tradeoff between the multiple criterion's that we are using for the design. Since the metrics are diverse with a conflict in queue time (which is to be minimized) and number of readers (which is to be minimized to reduce cost) the design point is a tradeoff between the 3 metrics. It is a solution that best satisfies all three criteria.

The objective function to be minimized is the Cost subject to the competing constraints of reliability and queue time. Increasing the number of readers reduces the queue waiting time; this strategy increases the cost and lowers the reliability. On the other hand, reducing the number of readers increases the queue waiting time; this strategy reduces cost and improves reliability. So a design point has to be found which satisfies all three criteria. The reliability of the system has to be increased and the queue times have to be decreased.

The optimization is done using Microsoft Excel solver.

1. The solver takes as its inputs the target cell which contains the value of the objective function that has to be minimized/maximized. In my case Cost has to be minimized.

2. The other constraint is queue waiting time which has to be minimized and has a bound < k ₁

3. This objective function is minimized subject to the constraints of reliability which is given in another cell and has a bound > k₂.

4. In addition to this the various components (e.g., battery, card reader etc.) can be bought from two manufacturers each. Say xi (for the reader), yj (for the battery), kl (for the communication system). If one of the manufacturer is selected the other is automatically deselected so the constraint is defined as:

   • xi = 1 .... i=1,2..
   • yi = 1 .... i=1,2..
   • k1 = 1 .... i=1,2..
   • In addition we would like that all the three components be bought from the same manufacturer so ?(xi yj kl ) =1

5. The other constraints that apply would be that the number of readers is an integer and should be greater than 1 and the number of engineers working on the system should be an integer and greater than two. The system will give us the best value of the number of readers that satisfies all three criteria of cost, reliability and the queue waiting times.

Normalized Equations

Metric 1. Cost (minimize)

    Total Cost = R*(X1*$1.2+X2*$1 + Y1*$1+Y2*$1.6 +K1*$0.5+K2*$0.3)+ $0.1*W

where R = number of card Readers;

Metric 2. Minimize Time to clear one employee

    Time = 0.5*(ca^2+cp^2) *(rho)^ ((sqrt (2*R+2)-1)) /(mu*(1-(rho))*R) < k1 Time

Here, ca and cp are the coefficients for arrival and departure given as c= standard deviation / mean, rho is the average utilization factor, percentage the server is busy, mu is the service rate of one server (in service/transaction per time unit)

Metric 3. Reliability (maximize)

    Reliability = (Rcard)^(R*Xi)*(Rbattery)^(R*Yj)*(Rcomm)^(R*Kl) < k2

This model assumes that reliability is the product of independent component reliabilities with:

• X_i =Boolean variable giving manufacturer; i= 1,2
• Y_j =Boolean variable giving manufacturer; j= 1,2
• k_l =Boolean variable giving manufacturer; l= 1,2

Equations in EXCEL Format

Objective function

Min:

    (1.2*B61+1*B62+B63+1.6*B64+0.5* B65+0.3*B66)*B17+0.1*C17…….Cost

Constraints

    0.5*(C16/C15)^2 *(C15/( 0.06667*B61+0.057143*B62))^ ((sqrt (2*B17+2)-1)) 
    /(H6*(1-(C15/( 0.06667*B61+0.057143*B62)))*B17)< N1 Time

    0.99^(B61*B17)* 0.95^(B62*B17)*0.998^(B17*B63)*0.98^(B17*B64) 
    *0.9819^(B17*B65)*0.978^(B17*B66)> N2 Reliability

    0<= B61<= 1
    0<= B62<= 1
    0<= B63<= 1
    0<= B64<= 1
    0<= B65<= 1
    0<= B66<= 1

    B61= int	    ..Manufacturer1 for card+reader
    B62= int	    ..Manufacturer2 for card+reader
    B63= int	    ..Manufacturer1 for battery
    B64= int        ..Manufacturer2 for battery
    B65= int        ..Manufacturer1 for communication
    B66= int        ..Manufacturer2 for communication
    B17=>1          ..Number of Readers
    C17=>2          ..Number of engineers
    B17=int
    C17=int
    B61+B62=1
    B62+B63=1
    B64+B65=1
    B61*B65*B63+B62*B64*B66=1  ........Buy from the same manufacturer

Results

The following table gives the number of runs that were required to explore the design space and find the Pareto points. The constraints of time and reliability namely k1 and k2 were varied to find the cost (column: C), total time in system (W), queue waiting times (T) and Reliability (Re)

(**) Infeasible (since number of readers has to be an integer and the constraint is violated because the constraint values cannot be achieved). Possible solution points are 7 and 8

Analysis in Excel

Figure 14. Screendump of Excel linked to Optimization Module

Trade-Off Analysis Results

Cost versus Time

Figure 15. Tradeoff in Cost versus Time

Reliability versus Time

Figure 16. Tradeoff in Relability versus Time

Cost versus Reliability

Figure 17. Tradeoff in Cost versus Reliability

The Pareto point is 7. < 0.05 & > 90

Number of readers: R= 3; Cost= 8.3; Time= 0.039; Reliability= 0.91

This has been selected after deciding that this point gives the best results for all three objectives. Since reliability is an important criteria in access control system it is important to maintain reliability at least < 0.90. Also a system that doesn't give a reliability of 0.9 might incur additional losses in repair and downtime. The Cost has to be kept low, however for an identification system cost is not the most important criteria. Also the number of readers in a system should be such that the queue waiting times are within specifications.

System Test Plan

Insert material, Fall Semester 2003 .....

Insert references from ENSE 621 ....

Developed by Rajeshree Varangaonkar, Spring Semester 2003
Reformatted and slightly modified by Mark Austin, May 2003
Copyright © 2003, Rajeshree Varangaonkar, John Baras and Mark Austin. All rights reserved.