1 - University of Texas at Dallas



Home Appliance Control System

Design Specification: Phase 1

10/12/2006

Group 3:

Rahul Sharma

Carl Fernandes

Ramakrishnan Jayavelu

Jonathan Burke

Naziya Sultana

Siddharth Phadkar

Michael Zima

Table of Contents

1. Introduction 3

1.1 Purpose 3

1.2 Scope 3

1.3 Assumptions 3

1.4 Requirement Specifications 4

2. Use Cases 5

3. Sequence Diagrams 6

3.1.1 Login (original) 6

3.1.2 Login (revised) 7

3.2.1 Get status (original) 8

3.2.2 Get status (revised) 9

3.3.1 Set Status (original) 11

3.3.2 Set Status(revised) 12

3.4.1 Add Appliance 14

3.5.1 Remove Appliance 15

3.6.1 Register Wireless (original) 16

3.6.2 Register Wireless (revised) 17

3.7.1 Alert System 19

4. CRC Cards 20

4.1.1 Appliance 20

4.2.1 Oven 21

4.3.1 Garage Door 22

4.4 Light 23

4.5.1 Alert Controller 24

5. Class Diagrams 25

5.1 HACS System 25

5.2.1 Alert System 26

1. Introduction

1. Purpose

The Home Appliance Control System (HACS) is intended to allow a user to set and control his home appliances remotely through interfaces such as a cell phone or the Internet. Appliances (such as ovens, microwaves, garage doors, windows, sprinklers, and alarm systems) will have embedded processing units to process remote commands and maintain the user’s desired settings while they are away.

2. Scope

• The system will be composed of a central controller, emergency alert system, and individual devices.

• The central controller handles communication between appliances and interaction with user interfaces.

• The emergency alert system monitors the safety states of each appliance and reports to emergency services (Police Station, Fire Department) if there is an emergency.

• Individual appliances will be capable of detecting changes in the environment and adapting their settings accordingly.

• The initial set of appliances defined by this specification are oven, window, lights, air conditioner, and fire alarm. Appliances can be added and removed later.

• Through threading the system will allow multiple users for a single home.

3. Assumptions

• The development team assumes the role of the set of users.

• While designing the initial system we have assumed there are no power failures. Later iterations of HACS should include backup and recovery functions to handle power failures.

• Like power failures in this iteration of HACS there is assumed to be no network failures. Later iterations should compensate for network failures.

• Each appliance has sufficient power and a dedicated CPU.

• For developing this system the wireless network is assumed to work the same way as a LAN.

• HACS has an Internet connection.

• Cellular reception is assumed to be perfect though later systems should handle poor cellular reception.

4. Requirement Specifications

• Allow users to check the status of their appliances, even when not at home

• HACS should be able to communicate with all appliances.

• Activate and deactivate appliances

• Alert users and emergency departments to critical malfunctions. Here HACS should maintain the safety of the user’s home and person at all times. Devices should be maintained in non-hazardous states.

• Be able to accept any HACS compatible appliance

• The system will be able to detect changes within the home and maintain the user settings.

• The user can set the status of different appliances manually and user commands have precedence over automatic commands.

2. Use Cases

Figure 2.1 is the Use Case diagram for the Home Appliance Control System. A single diagram is all that is needed due to the relatively small scope of the first phase/iteration of the system. Covered here are all necessary activities with respect to each of the system’s actors. Note that though the system boundary is not drawn that all use cases fall within the system boundary and all the actors are outside of it.

Figure 2.1.1: HACS Use Case Diagram

3. Sequence Diagrams

3.1.1 Login (original)

The login sequence was originally designed to provide HACS with a way of identifying a user and verifying that they are aloud to change appliance settings. Normally, Login would be used by any command issued to the HACS (setStatus, getStatus) from the user.

[pic]

Figure 3.1.1: Original Login Sequence

Flow of Events

1. The user dials in the mobile device number into a user interface.

2. The user interface sends the mobile device number to HACS.

3. HACS verifies the password against an array of known/allowed User’s via an array of UserRecords.

4. The verification result is stored by HACS.

3.1.2 Login (revised)

Like the original Login sequence the revised sequence (figure 3.12) passes a user or in this case mobile device number through a user interface. However, to increase security the HACS also requests a password from the user.

Figure 3.1.2: Revised Login Sequence

Flow of Events

1. Through a user interface the user dials into (initiates connection procedures) the HACS.

2. The interface attempts to connect to the HACS.

3. After connection, HACS requests a password from the user via the user interface.

4. The user dials in the password.

5. The user interface passes the password to HACS with a request to verify it.

6. HACS creates a user record initialized with the mobile device number and password of the user.

7. The database of known/allowed users is queried for a record matching the newly created user record.

8. The result of this query is passed to the User Record.

9. The HACS receives the query result via User Record.

3.2.1 Get status (original)

The Get Status sequence is designed to report the status of all attributes of an appliance to the user with the exception of reporting emergency states. We originally planned a simpler version of Get Status that used the original Login sequence (Figure 3.2.1)

Figure 3.2.1: Original Get Status Sequence

Flow of Events

1. The User selects the Appliance via the user interface.

2. The user interface passes on the appliance id for the selected appliance and the User Id to HACS.

3. HACS will first verify the user id before issuing a get status to the appliance.

4. The appliance will then return the status to HACS.

5. The HACS returns the appliance’s status to the user interface.

6. The user interface displays the appliance’s status to the user.

3.2.2 Get status (revised)

The new Get Status sequence includes specifics that went unmentioned in the original as well as updates the sequence for the revised Login sequence.

[pic]

Figure 3.2.2: Revised Get Status Sequence

Flow of Events:

1. The user logs in using the Login sequence (which is pictured again above).

2. HACS verifies that all the appliances it has listed in its connections list are actually connected by issuing a connection verification.

3. HACS builds a list of appliances based on appliances that respond.

4. HACS returns this list to the User Interface which displays a form based on the connections list.

5. The user selects an appliance from this list on the user interface.

6. The user interface queries HACS for this appliance’s status.

7. HACS establishes a connection to the appliance, and asks for the appliances status.

8. The appliance returns its status to HACS.

9. HACS returns the appliance status to the user interface, which displays it to the user.

3.3.1 Set Status (original)

Set Status is the sequence the designed to allow the user to change any attribute of a specific appliance. Set Status has also undergone a redesign to match the modified version of Login, which it uses, and to clear up some ambiguities.

[pic]

Figure 3.3.1: Set Status Sequence

Flow of Events

1. The user selects an appliance via the user interface.

2. The interface passes the following parameters: appliance ID, User ID, attribute and value, which are necessary to change the appliance’s specific attribute.

3. HACS verifies the User Id before issuing the set status command to the appliance.

4. After the status has been set, the appliance returns its current status to HACS.

5. The HACS returns the appliance to the User Interface.

6. The user interface displays the new status to the user.

3.3.2 Set Status(revised)

The revised version of Set Status incorporates the changes made to the Login sequence and further specifies previously ambiguous sequences of Get Status.

[pic]Figure 3.3.2: Revised Set Status Sequence

Flow of Events*

1. The user logs in using the Login sequence (which is pictured again above).

2. HACS verifies that all the appliances it has listed in its connections list are actually connected by issuing a connection verification.

3. HACS builds a list of appliances based on appliances that respond.

4. HACS returns this list to the User Interface which displays a form based on the connections list.

5. The user selects an appliance from this list on the user interface.

6. The user interface queries HACS for this appliance’s status.

7. HACS establishes a connection to the appliance, and asks for the appliances status.

8. The appliance returns its status to HACS.

9. HACS returns the appliance status to the user interface, which displays it to the user.

10. The user, viewing the appliances status, selects the attribute of the current appliance and sets a value to it.

11. The user interfaces issues a command to HACS asking it to set the status of the selected attribute to the selected value for the appliance which was chosen earlier.

12. HACS connects to the selected appliance and issues a command to set its status according to the previous step.

13. The appliance returns the result of the Set Status command to HACS.

14. HACS returns the result to the user interface which displays it to the user.

*Note: The first 9 steps of this sequence are identical to Get Status. If this is correct it should be indicated properly in the sequence diagrams for the purposes of identifying areas of possible reuse and for simpler code. We could perhaps use relationship if we plan to optionally set an appliances status only from a user form for which Get Status has already occurred.

3.4.1 Add Appliance

Add appliance describes the sequence of steps necessary to identify a new appliance with the Home Appliance Control System.

[pic]

Figure 3.4.1: Add Appliance Sequence

3.4.1 Flow of Events

1. The user carries out the initial appliance setup.

2. Values of appliance identification attributes like appliance ID are entered into the interface which can be implemented in a number ways using a cell phone, web etc.

3. The above values are configured in the HACS.

4. The HACS then sends a request to detect the appliance.

5. The appliance provides a reply in return which is taken as the acknowledgement signal.

6. The appliance is then added into the HACS.

7. The appliance will now start providing regular status updates to the HACS.

8. The user then provides range of allowed values for these attributes.

9. These are stored by the HACS.

3.5.1 Remove Appliance

Remove Appliance is designed to allow the deletion of an appliance from HACS list of known appliances and cease any actions taken between the user and the appliance.

[pic]

Figure 3.5.1: Remove Appliance Sequence

Flow of Events

1. The user sends a request to remove some appliance.

2. The request is forwarded via the interface to the HACS system.

3. The appliance is removed from the HACS system.

4. The system receives a notification confirming this.

5. This is sent to the user via the user interface.

6. The user interface alerts the user of the appliance’s removal.

3.6.1 Register Wireless (original)

Register wireless has two versions like other sequences mentioned above. The first is less specific and was conceived before the revisions to the mentioned sequences. The intent of Register Wireless is to add a new wireless device to the system but the sequence is similar to that of registering any new device with an interface to the system.

[pic]

Figure 3.6.1: Original Register Wireless Sequence

Flow of Events

1. A new MDN is added into the HACS and associated with the new wireless device.

2. The user provides the details necessary to configure the new device.

3. HACS communicates with the device to attempt to verify a connection.

4. The device response is then sent to the HACS to make sure the connection is done.

5. Device identification details like device ID are entered into the HACS.

3.6.2 Register Wireless (revised)

This revised Register Wireless sequence is more consistent with the revisions in the previous sequences. It also addresses specifics that were left unaddressed by the previous Register Wireless diagram. Finally, it suggests that a wireless device will be represented as a UserInterface or that at least a wireless device must implement the UserInterface as an interface (in the sense of J2EE/UML) among the other software on which the device operates.

[pic]

Figure 3.6.2: Revised Register Wireless Sequence

Flow of Events

1. The user selects the command AddWireless from an existing user interface (called “old” in the diagram).

2. Prompted by the user interface the User enters the information (MDN, Password) of a new user interface to connect (“new” in the diagram).

3. The user interface asks HACS to create a new UserRecord in its user database, a user record associated a wireless device with the password a user set for it.

4. HACS creates a new record to hold the information about the new device and attempts to insert this record into the user database.

5. The user database accepts the insert process and reports the operation successful.

6. Success is reported to the HACS, and it is in turn reported to the “old” user interface and displayed to the user.

7. HACS attempts to connect to the newly added device “new”.

8. “new” acknowledges the connection.

9. HACS reports the successful connection to the user interface “old” which reports it to the user. Simultaneously, the “new” wireless device displays that it has successfully connected to HACS (perhaps as a small discreet icon so as not to interrupt other device processes).

3.7.1 Alert System

Alert system notifies the user and the police or fire department if there is a fire or a security breach at a HACS equipped home. The hardware used to detect a fire or intruder interacts with HACS uses sockets as does most of the communication in the sequences already mentioned. Also the police department and fire department provide application program interfaces which HACS can use to notify the respective departments.

[pic]

Figure 3.7.1: Alert System Sequence

Flow of Events

1. Firstly the alert controller will create the necessary sockets and the start a thread which is individual from the main thread.

2. The new thread begins listening to a socket for messages from the hardware interface which interacts with the alert controller through sockets.

3. When ever this dedicated thread gets any message from the hard ware interface in case there is a fire or there is a security breach in the home it forwards the request to the alert controller(in the emergency controller a thread is dedicated to listen to the message from the alert controller).

4. The alert controller demultiplexes the request contacts the fire or police department.

5. The alert controller notifies the user.

4. CRC Cards

CRC cards are used as brain storming tools in Object oriented programming to reduce the complexity during the development process. The CRC cards below represent a more general view of our current interpretation of the system as defined by the requirements specification. The class diagrams below the CRC diagrams represent a more specific view.

4.1.1 Appliance

[pic]

Figure 4.1.1: Appliance CRC

• In this CRC card, Appliance is a Class that collaborates with the HACS and Appliance subclasses. The responsibility for this class is to communicate between its subclasses for each appliance and HACS class.

• Object is the super class for all the classes in the J2ee programming.

4.2.1 Oven

[pic]

Figure 4.2.1: Oven CRC

• This CRC card gives a clear view of the responsibilities and interactions of the Oven class.

• The responsibilities of the Oven class, besides switching on/off the oven, include: changing the temperature and mode, setting the timer, and reporting exceptional conditions.

• In order to perform these responsibilities Oven has to interact with HACS and Alert controller classes.

4.3.1 Garage Door

[pic]

Figure 4.3.1: Garage Door CRC

• This CRC card gives a clear view of the responsibilities and interactions of the Garage door class.

• The responsibilities of the Garage door class besides open/close include reporting exceptional conditions to the Alert controller class.

• In order to perform these responsibilities it has to interact with HACS and Alert controller classes.

4.4 Light

[pic]

Figure 4.4.1: Light CRC

• This CRC card gives a clear view of the responsibilities and interactions of the Light class.

• The responsibilities of the Light class besides switching on/off the light include changing the intensity and reporting exceptional conditions to the Alert controller.

• In order to perform these responsibilities it has to interact with HACS and Alert controller classes.

4.5.1 Alert Controller

[pic]

Figure 4.5.1: Appliance CRC

• This CRC card gives a clear view of the responsibilities and interactions of the Alert controller class. This is one of the important classes of the system; it interacts with most of the other classes.

• The responsibilities of the Alert controller class are to control all the alerts given by the appliances, alerting emergency departments and to pass exceptions to the HACS.

• In order to perform these responsibilities it has to interact with HACS, Appliance, its subclasses, and Emergency department.

5. Class Diagrams

The class diagrams below are intended to show the general structure of the HACS system and its subcomponents. Due to recent user consultations (i.e in class discussion/presentation) the class diagrams below have become outdated. Therefore, they are currently incomplete. However, as the most general structure of the class has not changed and since the revisions made mostly just increase our current models degree of specificity, the diagrams below can still be used to grasp a structural outline of the system.

5.1 HACS System

[pic]

Figure 5.5.1: General Class Diagram

5.2.1 Alert System

[pic]

Figure 5.2.1: Emergency Alert Class Diagram

[pic]

-----------------------

Add Appliance

Appliance

Remove Appliance

User

Set Status

Get Status

Emergency Alert

Register Wireless

Login

FireDept

PoliceDept

displayStatus

returnStatus

returnStatus

getStatus()

User : User

store range limits

set range limits

provide response

add appliance

provide ACK

detect appliance

configure appliance settings

provide appliance identification details

setup appliance

xyz:Appliance

:HACS

:UserInterface

User : User

notify

Send new status

notify

remove appliance

request remove appliance

request remove appliance

:appliance

:HACS

:UserInterface

User : User

send confirmation

add device

provide identification details

add user

xyz:Wireless

:HACS

Hacs notified on socket

sockets

communicate on

assumed devices

Here it is

Hacs notified on socket

department

wid specific

communication

or sockets for

will use some api

Notify_request()

connect to data base

connect to data base

Demultiplex_request()

forward request on socket

start_sensing()

start_threads()

create_sockets()

:Fire

:Police

Emergency_dept

emergency:

oller

abc:Alert_contr

e

:Device_interfac

:Hacs

HACS

Appliance

Appliance subclasses

Emergency Department

Control Alerts

Pass Exceptions to HACS

Alert Emergency Departments

Object

Alert Controller

HACS

Alert Controller

On

Off

Set Intensity

Report Exceptions

Appliance

Light

Open

Close

Report Exceptions

HACS

Alert Controller

Garage Door

Appliance

HACS

Alert Controller

Report Exceptions

Change Temperature

Change Mode

Set Timer

Turn On/Off

Appliance

Oven

HACS

Appliance Subclasses

Interface between HACS and specific appliances

Object

Appliance

alert(hid)

set(attribute, value)

get(attribute)

hid

attributes

appId

appliance

Login()

notify()

delAppliance()

addAppliance()

setStatus()

getStatus()

connections

EMservices

apps

userRecords

hid

HACS

getId()

setId(user_id)

user_id

UserRecord

getAppliances(hid)

setStatus(hid, appliance, attribute, value)

getStatus(hid, appliance)

displayWindow(window)

Connect(uid)

hid

uid

currentWindow

UserInterface

setIntensity(value)

off()

on()

lights

detectMotion()

setSecurity(on_off)

Windows

close()

open()

GarageDoor

detect()

FireAlarm

system

internet address for the Hacs

Note hid will contain perhaps an

Login

getStatus(app,uid)

selectApp

:Appliance

:HACS

:UserInterface

User: User

:HACS

: User

:UserInterface

:Appliance

selectApp

displayStatus

setStatus(app,uid,attribute, value)

Login

setStatus(attribute,value)

returnStatus

returnStatus

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download