Tags:
create new tag
, view all tags

Security Module of Smart Home

This document specifies use cases for the Security Module (SM) of Smart Home. Several configurations (or instances of this product line) are specified here. The goal is to read such specifications (or use case scenarios) and try to identify its common and variant elements. After that, these scenarios, which are not well modularized in this document, should be restructured using one specific approach for describing variabilities in use cases scenarios (PLUSS or Crosscutting).

In order to perform this work, we suggest the following sequence of activities:

  1. Read the different configurations of Smart Home Security Module
  2. Identifies the common and variable elements of the specification
  3. Represent a feature model describing the common and variant features
  4. Create instances of the feature model representing each configuration
  5. Restructure the product specific scenarios, generating a SPL use case model
  6. Relate features in the feature model to the scenarios in the use case model

The first activities are independent of the approach used for specifying variabilities in use case scenarios. On the other hand, activities (v) and (vi) are dependent of the selected approach.

For each activity, we expect the following outputs:

  1. Description of the technique applied in the execution.
  2. The amount of time required to perform the activity.

Overview of the Security Module

The SM offers one of the most expected subset of features for smart home configurations. It is responsible for detecting, notifying, and dealing with several security issues, such as intrusion and firing. This module can be customized in several ways, enabling the execution of different actions for each kind of event.

This module requires interaction with sensors for intrusion, presence, and fire detection; and may interact with different partners (police department, fireguard department, and so on) for dealing with each specific issue. Also, the system may provide different management mechanisms, both locally as remotely mechanisms, and provides different interfaces with the home owner.

Figure 1 depicts a high level view of SM use cases (just a scratch of the use case model). Then, in later sections, we describe detailed specifications of such use cases for different versions (products) of this module.

smart-home.jpg

Figure1: Security module use cases

Actors

Home Owner: Represents the home owner, being responsible for configuring the whole module.

Inhabitant: Represents an inhabitant of the smart home, which requires access for get in the home and also might configure policies for specific environment. Police and Fireguard Departments: Represent external systems that this module might interact in order to notify specific events.

Independent Fire Control System: Represent a third-part system responsible for handling with burn accidents. The full description of this system is out of the scope of this document.

Presence and Fire Sensors: Represent the devices used for detecting intrusion and fire issues.

Use cases

Configure Security Management: This use case allows the owner of a smart home to configure the security module behavior. Several characteristics may be configured, such as access policies, presence information, and so on.

Request Access to the Home: This use case allows a registered inhabitant of the smart home to enter into the house. Different techniques of controlling the inhabitant access can be deployed.

Configure Access to Specific Environments: This use case allows the configuration of access rules to specific environments. In order to change the access rules of a specific environment, an inhabitant must have sufficient privileges.

Intrusion Detection: This use case is responsible for catching any attempt to intrude the smart home. Several events are used to characterize this kind of attempt, such as doors and windows breaking.

Intrusion Detection: This use case is responsible for catching any attempt to intrude the smart home. Several events are used to characterize this kind of attempt, such as doors and windows breaking. If one of this events occurs, several actions might be triggered (lock the child bedroom doors, for instance).

Presence Detection: This use case is responsible for catching presence information when the house should be empty. If this event occurs, several actions might be triggered (place a call to the police department, for instance).

Fire Detection: This use case is responsible for identifying presence of fire or smoke inside the smart home.

In what follows, scenarios for three different configurations of this smart home module are described. It is important to notice that such descriptions are not well modularized, existing a high degree of duplication.

First Configuration

UC01- Configure Security Management

Description: This use case allows the owner of a smart home to configure the security module behavior. Several characteristics may be configured, such as access policies, presence information, and so on.

Scenario SC01 - Register Inhabitant

Description: This scenario allows the owner of the system to register new home inhabitants. In this way, the policies for entrance in the home are applied for them.

Precondition: The home owner is logged in the Security management system.

Flow of Events

User Action System Response
The home owner selects the register inhabitant option in the security configuration menu. The inhabitant personal form is displayed.
The home owner fills in the inhabitant personal form and selects the proceed option. The system requires the inhabitant password (and password confirmation) for getting access to the home.
The new inhabitant fills in the password (and confirmation password) for home access. The system requests the home owner configuration password.
The home owner fills in the configuration password and selects the proceed option. The system register the new inhabitant, allowing he (she) to access the smart house.

Scenario SC02 – Defines the home state

Description: This scenario allows the owner of smart home to change the house state .

Precondition: The home owner is logged in the Security management system.

Flow of Events

User Action System Response
The home owner selects the set home state option in the security configuration menu. The home state form is displayed, requiring the selection of one of the available states (house not empty, house empty)
The home owner selects one of the configured states. The system requests the home owner configuration password.
The home owner fills in the configuration password and selects the proceed option. The system updates the home state and activates the corresponding intrusion and presence policies.

Scenario SC03 – Define policies for home state

Description: This scenario allows the owner of smart home to change the policies for a specific home state.

Precondition: The home owner is logged in the Security management system.

Flow of Events

User Action System Response
The home owner selects the configure policies for home state option in the security configuration menu. The home state form is displayed, requiring the selection of one of the available states (house not empty, house empty)
The home owner selects one of the available states. The home state policy form is displayed, requiring: list of notification numbers, audio message, and text message.
The home owner fills in the requested information. The system requests the home owner configuration password.
The home owner fills in the configuration password and selects the proceed option. The system updates the home state and activates the corresponding intrusion and presence policies.

Scenario SC04 – Define rights for inhabitants

Description: This scenario allows the owner of smart home to change the rights for registered inhabitants, such as defining which home environments an inhabitant can configure access.

Precondition: The home owner is logged in he Security management system.

Flow of Events

User Action System Response
The home owner selects the configure rights for inhabitant option in the security configuration menu. The select an inhabitant form is displayed, requiring the selection of one of the registered inhabitants.
The home owner selects one of the registered inhabitants. The inhabitant rights form is displayed, requiring the home owner to inform if the inhabitant is able to entering in the house and which environments of the house the inhabitant can change the access control.
The home owner fills in the requested information. The system requests the home owner configuration password.
The home owner fills in the configuration password and selects the proceed option. The system updates the inhabitant rights and activates the corresponding policies.

UC02- Request Access to Home

Description: This use case allows a registered inhabitant of the smart home to enter into the house. Different means of controlling the inhabitant access can be deployed.

Scenario SC01 – Request Access to Home

Description: This scenario allows a registered inhabitant to enter into the house.

Precondition: -

Flow of Events

User Action System Response
The inhabitant request access to the home at the main entrance. The system requests to the user to pass the smart card.
The inhabitant pass the smart card in the card reader. The system requests to the user the password to access the smart home.
The inhabitant informs the access password. The system verifies that the password is valid for the registered inhabitant.
The system displays the message of success login.
The system opens the front door and register the occurrence.
After thirty seconds, the front door is closed.

Scenario SC02 – Request Access to Home, but inform a wrong password

Description: This scenario allows a registered inhabitant to enter into the house. But a wrong password is informed.

Precondition: -

Flow of Events

User Action System Response*
The inhabitant request access to the home at the main entrance. The system requests to the user to pass the smart card.
The inhabitant pass the smart card in the card reader. The system requests to the user the password to access the smart home.
The inhabitant informs the access password. The system verifies that the password is not valid for the registered inhabitant.
The system registers the occurrence.
The system request to the user to pass the smart card again, returning to the previews step. If the number of attempts is greater than three, the system sends an warning message for the home owner and blocks the inhabitant to enter into the house.

Scenrio SC03 – Guest Request Access to Home, but the house is empty

Description: This scenario allows a guest to enter into the house, however, the house is empty. This scenario is useful in cases where the home owner family is traveling but a employee, a relative or a close friend needs to enter into the house.

Precondition: -

Flow of Events

User Action System Response
The guest request access to the home at main entrance. The system requests the guest name and the reason for entering in the house.
The guest fills in the requested information. The system takes a guest photograph and sends one message to the home owner mobile device.
The system asks for the guest to wait a few minutes.
The home owner authorizes the guest to enter into the house. The system displays the message of authorized access.
The system opens the front door and register the occurrence.
After thirty seconds, the front door is closed.

Scenario SC04 – Guest Request Access to Home, but the house is empty and the home owner do not authorize it.

Description: This scenario is an exception flow of the previous one. It describes an unauthorized request of a guest to enter into the house.

Precondition: -

Flow of Events

User Action *System Response
The guest request access to the home at main entrance. The system requests the guest name and the reason for entering in the house.
The guest fills in the requested information. The system takes a guest photograph and sends one message to the home owner mobile device.
The system asks for the guest to wait a few minutes.
The home owner do not authorize the guest to enter into the house. The system displays the message of unauthorized access.
The system asks the guest to place a call to the home owner. The scenario finishes.

-- RodrigoBonifacio - 09 Apr 2008

Edit | Attach | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2008-04-09 - RodrigoBonifacio
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

mersin escort bayan adana escort bayan izmit escort ankara escort bursa escort