Software Requirements Document for Safe Homesmarthome.cs.iastate.edu/documents/SRS/SmartHome_SRS-6.pdfThe purpose of this document is the detailed requirements placed on the Smart

Software Requirements Document for Safe Home

Jason Stanek ([email protected])

Sean Stanek ([email protected])

Doug Houghton ([email protected])

Version Date Author Change

0.1 11/23/04 Initial document

0.2 11/25/04 Addition of requirements

0.3 11/29/04 Formal addition of use cases and requirements

refinement

0.4 12/02/04 More additions of use cases, further refinement

0.5 12/06/04 Completion of remaining sections

0.6 12/10/04 Refinement of entire document

Safe Home Device Management System Introduction Stanek, Stanek, & Houghton Page 2 of 30

Table of Contents

1 Introduction .........................................................................................................................3

1.1 Purpose................................................................................................................................................ 3 1.2 Scope ................................................................................................................................................... 3 1.3 Definitions, acronymns, abbreviations ................................................................................................. 3 1.4 References........................................................................................................................................... 4 1.5 Overview .............................................................................................................................................. 4

2 Overall Description .............................................................................................................6

2.1 Product Perspective ............................................................................................................................. 7 2.2 Product functions ............................................................................................................................... 15 2.3 User characteristics............................................................................................................................ 15 2.4 Constraints ......................................................................................................................................... 15 2.5 Assumptions and Dependencies........................................................................................................ 15

3 Specific Requirements .....................................................................................................16

3.1 External Interface Requirements........................................................................................................ 16 3.2 CLASSES........................................................................................................................................... 19 3.3 Performance requirements................................................................................................................. 21 3.4 Design Constraints............................................................................................................................. 28 3.5 Software System Attributes................................................................................................................ 28 3.6 Other Requirements........................................................................................................................... 28

4 Appendix............................................................................................................................29


1 Introduction

1.1 PURPOSE

The purpose of this document is the detailed requirements placed on the Smart Home’s device

management system and serves as a contract between Dr Simanta Mitra and the authors, as to

what is expected of the Smart Home device management system, and how the components of this

system are to work with each other and with external systems.

1.2 SCOPE

This document covers the details of the Smart Home’s device management system, including the

physical components of the system, as well as the behavioral, functional, and non-functional

requirements. Furthermore, it includes a description of the relevant external systems.

1.3 DEFINITIONS, ACRONYMNS, ABBREVIATIONS

Term Description

Smart Home This is the name of the laboratory on the Iowa State Campus. Device Management System (DMS)

This is the particular sub-system of the laboratory being discussed and outline in this document.

Device An component or sensor, utilized in Safe Home research, that is connected to the Safe Home computer system.

Stream A data source that could be a file or device that provides a series of states or events that can be read in sequential order.

Table 1: Term Definitions


1.4 REFERENCES

Jinchun, Josh, Mack, & Ruchi. “Safe Home Vision Document Version 1”.

Computer Science 509X. 24 pages.

Mitra, Simanta. “Safe Home Framework: Needs & Features”.


Sean, Jason, & Doug. “Vision & Scope Document for Smart Home”.


1.5 OVERVIEW

Perhaps one of America’s largest generations, the “baby boomers” are rapidly approaching their

retirement age. This generation, more so than many of those before it, are people with a strong

desire to maintain their independence long into their elderly years. However, as many people age

their abilities necessary to ensure their independence and self-supportiveness begin to fade and

fail. This massive portion of population will soon be seeking technological solution to aid them in

their daily tasks and duties to ensure their self-dependence, in an effort to avoid tradition support

such as nursing homes and elderly aids.

A second demographic which benefits from the same work, is those whose abilities have been

impaired. Those who have, in some fashion, have lost the ability to be self supportive. These

individuals also seek technological solutions to ensure their independence.

Finally, many people choose to lavishly shower themselves in luxury. Spending millions of dollars

per year on items and technologies whose sole purpose is the simplification and reduction of daily

chores and tasks. These people are continuously seeking technological solutions to save time and

ease everyday tasks.

Moreover, around the country numerous organizations have taken on projects to develop assisted

and advanced living. Some of these projects focus on the elderly, others on the handicapped, and

yet others on luxury. However, these few projects are still in their infancy and the market has many

caveats yet to be uncovered and developed. The Smart Home project offers the opportunity and

flexibility for students and researchers to explore those opportunities.


Smart Home is the development of a project at the axis of numerous markets. As mentioned

previously, an aging population’s needs for self sufficiency merits the need for better homes which

are able to support and aid in the completion of daily tasks and chores. The gap between the

abilities of certain lesser-able persons and their needs for personal independence merits better

homes that can ease complex and difficult tasks. Moreover, the human desire for luxury and

extravagance. As technologies become more affordable and less intrusive, they become more

incorporated into everyday devices and processes. Most machines and household items now

contain computers and technologically smart components. Smart Home is simply the next step,

providing a framework and architecture for the interoperability of such devices to aid in chores and

difficult tasks.

Smart Home is the logical next step in the modernization and incorporation of technology in the

modern home. Smart Home provides a platform to research, develop and support devices and

technologies to assist with tasks of the home. Moreover, the Smart Home framework creates an

environment in which devices and technologies in the home can work together. Smart Home takes

technologies already incorporated into many homes, and provides the ability for those devices, as

well as new, to operate together. Without Smart Home and the framework it provides, much of the

functionality and benefits of increasingly smart technological home devices is lost or wasted.

Safe Home Device Management System Overall Description Stanek, Stanek, & Houghton Page 6 of 30

2 Overall Description

The Computer Science 509X class, through this and similar documents, seeks to clarify and

describe the basic requirements of the Safe Home laboratory. This particular document is focused

on the device management system (DMS) of this lab.

The DMS of the Safe Home laboratory has a number of crucial functionalities. First, it provides the

interface for the connectivity of devices into the Safe Home system. Secondly, it provides the lab

with the ability to utilize devices of varying types, and most importantly varying connectivity types.

Another core functionality of the DMS is ease of device use. That is, the DMS provides the lab with

the ability to have devices plug-and-play. The DMS will also provide a platform for all the varying

devices to communicate and operate cooperatively. A final functionality of the DMS, is the ability to

add, remove, reconfigure, of modify any device without halting or compromising the systems

integrity.

The DMS portion of the Safe Home laboratory is comprised of a number of core components:

• Device Registrar – this system controls the addition, system registration, disconnection,

and system removal of devices.

• Device Controller – this system allows for the enabling/ disabling of devices, as well as the

reconfiguration, modification, and trouble-shooting devices.

• Device Interface – this system provides the interface for application to access the devices,

as well as providing the interface for devices to communicate with each other.

• Driver Manager – this system allows for the addition, removal, upgrading, and modification

of device drivers.


2.1 PRODUCT PERSPECTIVE

There are a number of Safe Home projects, in various stages of productivity, across the United

States. Some of these include Adaptive House, Aware Home, CyberManor, and the Smart House.

More specific to the device management aspect of the project, there is the Niagra Framework. The

following section briefly explains these competitive products, and how the Safe Home DMS relates

to each.

Assisted Living

See appendix 4.1.1.

Nursing Homes

See appendix 4.1.2.

Gator Tech Smart House, University of Florida

See appendix 4.1.3.

Niagra Framework, Tridium

See appendix 4.1.4.

2.2 CONCEPT OF OPERATIONS

The main function of the DMS is to control and maintain the devices utilized by the Safe Home

Laboratory. Specifically, the DMS creates an easy-to-use and easy-to-understand interface by

which devices are added, managed, and removed.


2.3 MAJOR USER INTERFACES

User Researcher

Application Device

List Applications

List Devices

Change Application Options

Install Devices and Applications

Run Application

Change State

Create Event

Interpret Commands

Configure Application

Simulate Devices

Replay

Record

Analyze Performance

Examine Device State

Handle Events

Create Event

Add User Options

Examine User Options


2.3.1 SETTING USER OPTIONS

2.3.1.1 Use Case for Setting User Options

Name: Setting Options Use Case for User/Researcher

Description: The user options allow the user to set preferences for application settings that the

developer has made available. This can be made available through a web form, cell phone, or PDA.

Actor: User, Researcher

Basic-Flow: The user is presented with a list of Smart-Home applications currently running. The

user selects an application and is presented with a set of application specific options. The user

selects his preferences and submits the changes. The application is notified about the change in

settings and the user is notified with a success confirmation message.

Alternate-Flow: A conflict or other failure of option settings results in a failure message with a

corresponding reason for the failure.

Preconditions: User must be logged into the system. Applications must be running in the system.

Postconditions: User will be informed of his success or failure.

SEQUENCE DIAGRAMS FOR ALL USE CASES TODO

2.3.2 INSTALLING A DEVICE

2.3.2.1 Use Case for Installing a Device

Name: Device Installation Use Case for User/Researcher

Description: The system is extendible in terms of the number of devices and applications, so from

time to time the user or researcher might want to add devices to the Smart-Home system for using

or testing. Upon the addition of these devices, and associated driver and/or application may be

installed with it.


Basic-Flow: The actor plugs in a device, which is recognized by the OS through Plug-and-Play.

The operating system installs the correct driver and application, and notifies the Smart-Home


device manager of the newly available device. The installation program reports success or failure

for the device and/or application.

Alternate-Flow: The user may choose to manually install a device, driver, and associated

application. This may also be the only choice in the case that the operating system does not support

Plug-and-Play, or the operating system cannot otherwise recognize the device. Manual install is

accomplished by plugging in the device and running a custom setup program, which also reports

success or failure.

Preconditions: The Smart-Home is running and ready to accept a new device.

Postconditions: The new device is ready for use by an application, and the user is informed of

installation’s success or failure.

2.3.3 RUNNING AN APPLICATION

2.3.3.1 Use Case for Running an Application

Name: Application Running Use Case for User/Researcher

Description: An application works on some subset of the system’s devices. These subsets may

overlap between applications. Allocation of these devices is handled by the device manager. There

may or may not be resource conflicts between applications. Since there are potentially many

different applications, and new applications will come to market, the user must have the ability to

add an application to the system. Researchers will mainly add applications for research and testing.


Basic-Flow: The researcher runs the specified application using a configuration file as a parameter.

This can be done from a command prompt, graphically using drag-and-drop, or a preset

configuration file could be read from somewhere. The researcher is informed of the success or

failure of starting the application, depending on resource availability.

Alternate-Flow: The user is presented with a list of available Smart-Home applications that he can

run. The user selects an application and is presented with the set of default application specific

options. The user selects his configuration and chooses the “Run” button. The user is informed of

the success or failure of starting the application, depending on resource availability.

Preconditions: The user or researcher is logged into the Smart-Home system.

Postconditions: Upon success, the application is registered with the device manager.


2.3.4 REQUESTING A RESOURCE OR A DEVICE

2.3.4.1 Use Case for Requesting a Resource or a Device

Name: Resource/Device Allocation Request Use Case for Application

Description: Applications use a subset of the system devices. There will be certain times when a

resource is needed and certain times when it is not needed. The application has the ability to

request and release resources depending on its needs.

Actor: Application

Basic-Flow: The application makes a request to the device manager. The device manager

determines if the resource is available for that application. The request may have privileges

associated with it, including shared and exclusive access rights. A handle for the resource is

returned to the application along with a success or failure code.

Alternate-Flow: None.

Preconditions: The application is currently running.

Postconditions: The resource handle is allocated by the device manager and the handle is returned

to the application for use on success.

2.3.5 SIMULATING DEVICE INPUT

2.3.5.1 Use Case for Simulating Device Input

Name: Device Input Simulation Use Case for Researcher/Application

Description: There are times when physical devices may not be available, or when a researcher

would like to test a device using simulated input by using a human interface device such as the

keyboard.

Actor: Researcher, Application

Basic-Flow: Researcher presses a key on the keyboard, or some other device, which has been

mapped to simulate a certain event or change in state associated with a device type. The state or

event queue of the data formatter for the associated virtual device is updated with the new

simulated information. The application may receive a callback in the case that an event is created.


Or, the application can use the updated state information during its polling period, and takes the

associated action transparently, as if it were real input.

Alternate-Flow: None.

Preconditions: A configuration file has been created and loaded that maps keys on a keyboard (or

other device) to an associated change in state or event creation for a specified simulated device.

Postconditions: The application receives the simulated state change or event.

2.3.6 REPLAY

2.3.6.1 Use Case for Replay

Name: Replay Use Case for Researcher/Application

Description: A researcher may want to replay a string of pseudo-randomly generated, thoughtfully

generated, or previously recorded states and events that describe an event or led to a system failure.

Actor: Researcher, Application

Basic-Flow: Researcher initiates the simulation replay, which replays states and events of devices

that are specified as simulated devices in the configuration file. The state or event queues of the

data formatters for the associated virtual devices are updated with new simulated information. The

application may receive a callback in the case that an event is created. Or, the application can use

the updated state information during its polling period, and takes the associated action

transparently, as if it were real input.

Alternate-Flow: The replay may be paused, continued, fast forwarded, rewound, stopped, or looped

at any time.

Preconditions: A configuration file has been created and loaded that specifies simulated devices

and their associated source streams to use for replay data.

Postconditions: The application receives the simulated state changes and events.

2.3.7 TOGGLING A LIGHT SWITCH

2.3.7.1 Use Case for Toggling a Light Switch

Name: Light Switch Toggling Use Case for User


Description: This is a simple use case that shows the flow of a simple user task such as turning on a

light.

Actor: User

Basic-Flow: The user toggles the external light switch device. The device sends an event to the

device driver, notifying the driver of the state change. The device driver forwards on the event

notification to the data formatter, which in turn may either call an event handler specified in the

application, or may simply change it’s recorded state of the device, which the application can poll

for. The application performs the appropriate action for the change in state.

Alternate-Flow: If the device is not in use by any application, the device’s event is discarded.

Preconditions: The Smart-Home system is running and an application using the device is running

and ready to accept input.

Postconditions: The application receives the simulated state changes and events.

2.4 EXAMPLE SCREENSHOT AND DESCRIPTION

See appendices for screenshots.

2.5 HARDWARE INTERFACES

2.5.1 COTS PCS

2.6 SOFTWARE INTERFACES

2.6.1 JAVA STRUTS FRAMEWORK


2.7 COMMUNICATION INTERFACES

2.7.1.1 USB

2.7.1.2 Firewire

2.7.1.3 Wireless (802.11b)

2.7.1.4 Wireless (Bluetooth)

2.7.1.5 Ethernet

2.8 MEMORY CONSTRAINTS

2.8.1 THE SYSTEM SHALL TAKE INTO ACCOUNT AVERAGE SYSTEM MEMORY

AVAILABILITY.

2.9 OPERATIONS

2.9.1 NONE.

2.10 SITE ADAPTATION REQUIREMENTS

2.10.1 THE SYSTEM SHALL BE COMPATIBLE WITH EXISTING

INFRASTRUCTURE.

2.10.2 THE SYSTEM SHALL BE UNINTRUSIVE TO THE USER.


2.11 PRODUCT FUNCTIONS

2.11.1 THE PRODUCT WILL AID IN DAILY ACTIVITIES.

2.12 USER CHARACTERISTICS

2.12.1 PRIMARY USERS ARE PEOPLE IN NEED OF ASSISTENCE IN DAILY

ACTIVITIES.

2.12.2 SECONDARY USERS ARE PEOPLE DEVELOPING APPLICATIONS FOR

RESEARCH PURPOSES.

2.13 CONSTRAINTS

2.13.1 COST – THE END PRODUCT SHALL BE REASONABLY PRICED.

2.13.2 SCALABILITY – THE SYSTEM SHALL BE AS SCALABLE AS THERE ARE

COMPUTING RESOURCES.

2.14 ASSUMPTIONS AND DEPENDENCIES

2.14.1 THE SYSTEM IS DEPENDENT ON THE JAVA STRUTS FRAMEWORK.

Safe Home Device Management System Specific Requirements Stanek, Stanek, & Houghton Page 16 of 30

3 Specific Requirements

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.1.1 THE OPTIONS MANAGER SHALL ACCEPT INPUT FROM ACOMMON USER

INTERFACE FOR VOICE, TOUCH SCREEN, PDA, AND CELL PHONE.

3.1.1.1 Options Manager

3.1.1.1.1 Enumerate Options – This function shall enumerate all available options from an

application’s option list.

3.1.1.1.2 Query Option – This function shall return the specified option handle.

3.1.1.1.3 Get Option – This function shall return the specified option’s current state.

3.1.1.1.4 Set Option – This function shall set the specified option’s current state.

3.1.2 THE OPTIONS MANAGER AND SIMULATOR SHALL INTERFACE WITH THE

EXTERNAL INFORMATION MANAGER SYSTEM.


3.1.2.1.1 Add Option – This function shall add an option to an application’s option list.

3.1.2.1.2 Remove Option – This function shall remove an option from an application’s

option list.






3.1.2.2 Simulator

3.1.2.2.1 Simulate Set – This function shall simulate data from the device.

3.1.2.2.2 Simulate Notification – This function shall simulate that a notification has come

from the device.

3.1.2.2.3 Simulate Disable – This function shall simulate that the device has been

disabled.

3.1.2.2.4 Simulate Failure – This function shall simulate a device failure.


3.1.3 THE DEVICE MANAGER, OPTIONS MANAGER, AND DATA FORMATTER

SHALL INTERFACE WITH THE RESEARCH SYSTEM VIA THE

RESEARCHERS’ PROGRAMMED APPLICATIONS.

3.1.3.1 Device Manager

3.1.3.1.1 Enumerate Devices – This function shall enumerate the currently available real

and simulated devices for an application.

3.1.3.1.2 Allocate Device – This function shall allocate a specified device if it is currently

available and has permissions to do so.

3.1.3.1.3 Free Device – This function shall deallocate a previously allocated device and

make it available for other applications to use.

3.1.3.1.4 Update Device Configuration – This function shall replace the current device

configuration for the application with a new device configuration.




option list.



3.1.3.3 Data Formatter

3.1.3.3.1 Get – This function shall return the associated device’s current state.

3.1.3.3.2 Set – This function shall set the associated device’s current state.

3.1.3.3.3 Notify Device –This function shall notify the associated device that this data

formatter is connected to of some event.

3.1.3.3.4 Disable – This function shall disable the associated device.

3.1.3.3.5 Handle Failure – This function shall handle a failure in the device and pass on a

device failure notification to the next component on the control path.


3.1.4 THE DATA FORMATTER AND SIMULATOR SHALL INTERFACE WITH THE

DEVICE DRIVER SYSTEM.

3.1.4.1 Data Formatter



3.1.4.2 Simulator



from the device.


disabled.



3.2 CLASSES

Research System

Data Formatter

Applications

Driver

Device

Device &

Driver System

Driver

Keyboard

Keyboard

Service

Info System

Service

Simulator

Driver

File

Information System User Inputs

Options

Manager

Options

Formatter

Options Manager

Options Formatter

Input

Device Manager

Configuration File

Device

Manager

Configuration

File

Info

System described in SRS

External System

Legend


3.2.1 DEVICE MANAGER

THE DEVICE MANAGER KEEPS TRACK OF DEVICES AND THE APPLICATIONS

WITH WHICH THEY ARE ASSOCIATED, AS WELL AS THE ASSOCIATED

CONFIGURATION FILE. IT IS RESPONSIBLE FOR UPDATING CONFIGURATIONS

FOR APPLICATIONS, RESOURCE MANAGEMENT FOR THE ENTIRE SYSTEM, AND

MUTUAL EXCLUSION.

3.2.1.1 Attributes

3.2.1.1.1 Applications – The system shall maintain a list of currently running researcher

applications or Smart-Home applications.

3.2.1.1.2 Devices – The system shall maintain a list of currently available devices and to

which applications they may be allocated to.

3.2.1.1.3 Configuration Files – The system shall associate a configuration file with each

application.

3.2.1.2 Entities

3.2.1.2.1 None.

3.2.1.3 Functions

3.2.1.3.1 Enumerate Devices – This function shall enumerate the currently available real

and simulated devices for an application.

3.2.1.3.2 Allocate Device – This function shall allocate a specified device if it is currently

available and has permissions to do so.

3.2.1.3.3 Free Device – This function shall deallocate a previously allocated device and

make it available for other applications to use.

3.2.1.3.4 Update Device Configuration – This function shall replace the current device

configuration for the application with a new device configuration.


3.2.1.4 Events

3.2.1.4.1 Reconfiguration – This event shall represent an update in a configuration file for

an application. The event updates the application configuration according to the

corresponding configuration file.

3.2.1.4.2 Device Failure – This event shall represent a failure that has occurred in the

hardware or software of a device that causes it to no longer function as expected.

3.2.1.4.3 Device Disable – This event shall represent that a device is no longer usable for

an application.

3.2.2 DATA FORMATTER

The data formatter takes the data from the devices or simulated devices, interprets the

data into a common format, and passes it to the application. The data may also be piped

to or from the information system in the event of a replay.

3.2.2.1 Attributes

3.2.2.1.1 Driver – The system shall have a pointer to a device driver for communication

between the data formatter and a real or simulated device.

3.2.2.1.2 Type – The system shall allow representation of the device type, such as a light,

a heat sensor, etc.

3.2.2.1.3 Data Values – The system shall have a place to store a device’s state information

depending on the data formatter type.

3.2.2.1.4 Event Queue – The system shall have an event queue for storing incoming and

outgoing events for a device.

3.2.2.1.5 Recording – The system shall be able to record events and states of a device for

future analysis or playback.

3.2.2.2 Entities

3.2.2.2.1 Boolean – The boolean data formatter shall allow a data value of true or false (or

on or off).

3.2.2.2.2 Analog – The analog data formatter shall allow a real number data value

between 0 and 1, inclusive.


3.2.2.2.3 Positional – The positional data formatter shall allow a 3-D coordinate data value.

3.2.2.2.4 Radio – The radio data formatter shall allow a data value that represents a single

selection of many items.

3.2.2.2.5 Data Streaming – The data streaming data formatter shall queue up streamed

data as its data value.

3.2.2.2.6 Simulated – The simulated data formatter shall allow any other type of data

formatter to be simulated without the need for a physical device.

3.2.2.2.7 Custom – The custom data formatter shall allow for a custom-defined, complex

device, composed of several real or simulated devices.

3.2.2.3 Functions



3.2.2.3.3 Update – This function shall update the current device driver for the associated

device.

3.2.2.3.4 Notify Application – This function shall notify the associated application that owns

this data formatter of some event.

3.2.2.3.5 Notify Device –This function shall notify the associated device that this data

formatter is connected to of some event.

3.2.2.3.6 Disable – This function shall disable the associated device.

3.2.2.3.7 Handle Failure – This function shall handle a failure in the device and pass on a

device failure notification to the next component on the control path.

3.2.2.3.8 Record – This function shall record all states and events that correspond to the

specified device, and store the data in the information system for future retrieval.

3.2.2.4 Events

3.2.2.4.1 Device Failure – This event shall represent a failure that has occurred in the

hardware or software of a device that causes it to no longer function as expected.

3.2.2.4.2 Notification – This event shall represent that some desired condition is true for

the device or application, and the application or driver (respectively) wanted to be

notified.


3.2.3 SIMULATOR

The simulator is responsible for simulating device information and events in the data

formatter, in a transparent way to the researcher and application. Simulation can be

specified in the configuration file. Simulation provides a method of simulating a virtual

environment for testing and analysis.

3.2.3.1 Attributes

3.2.3.1.1 Simulated Device Driver – The system shall allow a device driver to be simulated

in all aspects such that it functions exactly like a real device driver, only it returns pre-

recorded or pre-specified data from another driver (i.e. a researcher’s keyboard) or from

the information system.

3.2.3.1.2 Data Formatters – The system shall allow one or many data formatters to be

associated with the simulator system, to allow any or all devices to be simulated

simultaneously.

3.2.3.1.3 Configurations – The system shall allow for a configuration for each device to

determine whether that device is to be simulated, how it should be simulated, and from

what source it should be simulated.

3.2.3.2 Entities

3.2.3.2.1 Keyboard Service – The keyboard service shall allow keys on the researcher’s

keyboard to be mapped to certain data values and events that would otherwise be

returned from some other real device.

3.2.3.2.2 Replay Service – The replay service shall allow certain data values and events to

be replayed on the associated data formatter, from the information system

3.2.3.2.3 Custom Device Service – The custom device service allows data and event

simulation to occur from any other device in the system, so-as not to restrict the

simulator system to a single keyboard and replay service.

3.2.3.3 Functions



from the device.



disabled.


3.2.3.4 Events

3.2.3.4.1 Start – This event shall start the data simulation.

3.2.3.4.2 Stop – This event shall stop the data simulation.

3.2.4 DEVICE CONFIGURATION

The device configuration is a list of devices and their attributes. This can specify, for a

device, whether a device is real, simulated, recorded, replayed; and specifies permissions

for mutual exclusion.

3.2.4.1 Attributes

3.2.4.1.1 Application Handle – The system shall keep track of each application in the

Smart-Home system.

3.2.4.1.2 Device Handle – The system shall keep track of each device in the Smart-Home

system.

3.2.4.1.3 Device Type – The system shall keep track of each device’s type (light, heat

sensor, etc.).

3.2.4.1.4 Input Type – The system shall keep track of each device’s input format (boolean,

analog, etc.).

3.2.4.1.5 Permissions – The system shall keep track of usage permissions for each device

to ensure mutual exclusion (shared or exclusive).

3.2.4.2 Entities

3.2.4.2.1 None.

3.2.4.3 Functions


3.2.4.3.1 Update Device Handle – This function shall update a particular device handle in

the case that the device changes and the previous handle is no longer valid.

3.2.4.3.2 Update Permissions – This function shall update a particular device’s

permissions.

3.2.4.3.3 Update Input Type – This function shall update a particular device’s method of

data transfer.

3.2.4.4 Events

3.2.4.4.1 Configuration Change – This event shall represent that a change to a particular

application’s device configuration has occurred.

3.2.5 OPTIONS MANAGER

The options manager is responsible for allowing the application programmer to specify

higher level options available to the user. The user is able to configure the options through

the user input system, including voice, web, PDA, cell phone, etc., as previously specified.

3.2.5.1 Attributes

3.2.5.1.1 Applications – The system shall keep track of all application running within the

system.

3.2.5.1.2 Application UI Tag – The system shall keep track of a user understandable

representation of the application name.

3.2.5.1.3 Application Description Text – The system shall have a text description for each

application, to give the user a meaningful and non-technical understanding of the

application

3.2.5.1.4 Application Options – The system shall keep track of all options for a given

application.

3.2.5.1.5 Option UI Tag – The system shall keep track of a user understandable

representation of the option name.

3.2.5.1.6 Option Description Text – The system shall have a text description for each

application option, to give the user a meaningful and non-technical understanding of the

option.


3.2.5.2 Entities

3.2.5.2.1 None.

3.2.5.3 Functions



option list.






3.2.5.4 Events

3.2.5.4.1 New Application – This event shall represent that a new application has entered

the system, and must be added to the list of applications.

3.2.5.4.2 User Settings Request – This event shall represent a request made from

somewhere by the user, requesting access to the options manager.

3.2.6 OPTIONS FORMATTER

The options formatter is a parallel of the data formatter, except that it facilitates the

interaction between the user and the application for a specified option.

3.2.6.1 Attributes

3.2.6.1.1 Setting – The system shall keep track of the setting of each option.

3.2.6.1.2 ID – The system shall create a global unique identification number for each

option in the system.

3.2.6.2 Entities


3.2.6.2.1 Boolean – The boolean data formatter shall allow a data value of true or false (or

on or off).

3.2.6.2.2 Analog – The analog data formatter shall allow a real number data value

between 0 and 1, inclusive.

3.2.6.2.3 Positional – The positional data formatter shall allow a 3-D coordinate data value.

3.2.6.2.4 Radio – The radio data formatter shall allow a data value that represents a single

selection of many items.

3.2.6.2.5 Data Streaming – The data streaming data formatter shall queue up streamed

data as its data value.

3.2.6.2.6 Simulated – The simulated data formatter shall allow any other type of data

formatter to be simulated without the need for a physical device.

3.2.6.2.7 Custom – The custom data formatter shall allow for a custom-defined, complex

device, composed of several real or simulated devices.

3.2.6.3 Functions

3.2.6.3.1 Get Option – This function shall return the option’s setting (data value).

3.2.6.3.2 Set Option – This function shall set the option’s setting.

3.2.6.3.3 Notify Application – This function shall notify the associated application of a

change in an options setting.

3.2.6.3.4 Notify User Interface – This function shall notify the associated user interface of a

change in an options setting.

3.2.6.3.5 Record – This function shall record changes made to an option.

3.2.6.4 Events

3.2.6.4.1 Notification – This event is used to represent that the options manager should be

notified that an option’s setting has been changed.

3.3 PERFORMANCE REQUIREMENTS

The system shall support 100 devices per machine in the system. The system shall

provide device event service response times, prioritized by the real-time operating system,

of no more than 100 milliseconds.


3.4 DESIGN CONSTRAINTS

None.

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 RELIABILITY – THE SYSTEM SHALL HAVE A MEAN TIME TO FAILURE OF 30

DAYS.

3.5.2 AVAILABILITY – THE SYSTEM SHALL BE ONLINE 99% OF THE TIME.

3.5.3 SECURITY – THE SYSTEM SHALL ENSURE SECURITY AND PRIVACY.

3.5.4 MAINTAINABILITY – THE SYSTEM SHALL BE EASILY MAINTAINABLE THROUGH

THE USE OF OBJECT ORIENTED PRACTICES.

3.5.5 PORTABILITY – THE SYSTEM SHALL RUN ON ANY MACHINE CAPABLE OF

RUNNING THE JAVA JVM.

3.6 OTHER REQUIREMENTS

3.6.1 NONE.

Safe Home Device Management System Appendix Stanek, Stanek, & Houghton Page 29 of 30

4 Appendix

4.1 ALTERNATIVES AND COMPETITION

Note: This section quoted from the vision document by Chad Kilgore, Matt Peitz, Kendra Schmid.

4.1.1 Assisted Living Facilities: Assisted living facilities are for persons that need assistance with ADLs but wish to live as

independently as possible. Most assisted living facilities create a detailed service plan for

individual residents upon admission, which is updated regularly to assure that the resident receives

the appropriate care as his or her condition changes. These services include help preparing meals,

bathing, dressing, performing household chores, and aid for persons confused or experience

memory problems. Other common terms for assisted living are residential care, personal care, adult

congregate living care and supported care.2

4.1.2 Nursing Homes: Nursing homes provide skilled nursing care and rehabilitation services to people with illnesses,

injuries or functional disabilities. Even though most facilities serve the elderly, some facilities

provide services to younger individuals with special needs, such as the developmentally disabled,

mentally ill, and those needing drug and alcohol rehabilitation. Nursing homes are generally stand-

alone facilities, focusing their attention on rehabilitation, so that their residents can return to their

own homes as soon as possible. Some of the services provided by nursing homes include therapies,

pharmacy services, and specialty care, such as Alzheimer's treatment, neuromuscular diseases,

stroke recovery.3

4.1.3 University of Florida: “The RERC-Tech-Aging is testing currently available home monitoring products relative to their

effectiveness in relation to independence, quality of life and health related costs. The RERC-Tech-

Aging is also identifying needs and barriers to home monitoring and communication technology,

and addressing needs of special populations including rural-living elders, and people aging with

disability. The results of this research will be relevant to health policy makers, device developers,

and other investigators. The RERC-Tech-Aging works with companies on pre-product testing,

Safe Home Device Management System Appendix Stanek, Stanek, & Houghton Page 30 of 30

including Honeywell's very promising Independent LifeStyle Assistant (ILSA). We are advancing

very new consumer products such as Motorola's Smart Phone, to provide applications useful for

older people with disabilities. We are also studying the requirements for, and development of a

device / system for elders with cognitive impairment. We are applying the concept of pervasive

computing to the needs of older persons through our work with smart phones and smart homes.”4

4.1.4 Niagara Framework: The Niagara Framework, developed by Tridium Software, is a Java-based framework that allows

development of smart homes using different components from different manufactures. Niagara was

developed using JavaBeans that allows every component to be treated as an object. Niagara uses an

adapter development pattern so that every object, regardless of manufacture, communication

standard, or software can run from a standard web browser. The framework can then dictate to each

device what needs to be done its own protocol, thus saving time that would be used to program all

devices. The framework operates on a wide variety of hardware platforms and operating systems

due to Java development. The Niagara Framework differs from the project vision since the

framework is designed primarily for an electronic house, not necessarily a smart home.5

Documents

Software Requirements Document for Safe Homesmarthome.cs.iastate.edu/documents/SRS/SmartHome_SRS-6.pdfThe purpose of this document is the detailed requirements placed on the Smart