aadl c3 sds.doc

RFID Aged and Assisted Digital Living Project

Curtin University of Technology

Software Design Specification

Version 3.0 (Draft)

Last Updated: 24th October 2006

Revision History

Name Date Reason for Changes VersionAADL 17/05/2006 Initial version 1.0AADL 20/05/2006 1st Inspection 1.1AADL 21/05/2006 Test Provisions Section Added 1.2AADL 22/05/2006 2nd Inspection 1.3AADL 23/08/2006 Cycle 2 Design Specification 2.0 DraftAADL 2/09/2006 Cycle 2 Inspection 2.0AADL 24/10/2006 Cycle 3 Design Specification 3.0 Draft

Table of Contents

1. Introduction .................................................................................................................... 4 1.1 Purpose ................................................................................................................................. 4 1.2 Project Description ................................................................................................................ 4 1.3 Definitions, acronyms, and abbreviations ............................................................................. 4 1.4 References ............................................................................................................................. 4

2. Design Considerations ................................................................................................... 5 2.1 Goals and Guidelines ............................................................................................................ 5

3. System Architecture ...................................................................................................... 6 3.1 System Overview .................................................................................................................. 6 3.2 Detailed Description ............................................................................................................. 8 3.3 Database Design ................................................................................................................... 8 3.4 Use Case Diagram ............................................................................................................... 14 3.5 Use Case Scenarios and Sequence Diagrams ...................................................................... 15

3.4.1 Event Server ................................................................................................................. 15 3.4.1.1 Positioning .......................................................................................................... 15 3.4.1.2 Emergency Alert Handling ................................................................................. 17 3.4.1.3 Low Battery Alert Handling ............................................................................... 19 3.4.1.4 Motion Alert Handling ....................................................................................... 20 3.4.1.5 Check-In ............................................................................................................. 21 3.4.1.6 Check-Out .......................................................................................................... 23 3.4.1.7 Handle Lost Tag ................................................................................................. 25 3.4.1.8 Check Access Privileges ..................................................................................... 27 3.4.1.9 Cisco IP Phone Connector .................................................................................. 28

1. Introduction

1.1 Purpose

This document specifies the System Development Cycle 3 design of the Aged and Assisted Digital Living Project for the Netlink Group. For further details, refer to version 1.0, submitted on the 22nd May 2006 and version 2.0, submitted on the 2nd September 2006.

1.2 Project Description

The system has the primary goal of reducing overall operational costs for aged care providers, and at the same time enhancing the quality of service provided to aged care residents through the implementation of improved environmental monitoring techniques and better communication of information to staff. This can be achieved through an effective implementation of real-time Asset identification and tracking using RFID technology.

1.3 Definitions, acronyms, and abbreviations

Refer to SDS version 1.0.

Active Tag A tag is active if it is currently within the facility. A facility may be covered partially or completely by the Reader Network.

Registered Tag A tag is registered if it has been selected to be monitored.

MQ Message Queue.

1.4 References

Appleton, B. 1997, Software Design Specification Template, Retrieved August 16, 2006, from http://www.construx.com/survivalguide/desspec.doc

2. Design Considerations

This section describes many of the issues which need to be addressed and resolved before attempting to devise a complete design solution.

2.1 Goals and Guidelines

• Thin client at the Event Router level – the Event Router will be designed to be deployable on a maximum number of platforms which may have limited hardware resources.

• Cost Effectiveness – Software used should be license free where possible in order to minimise cost to the end client.

• Simple User Interface – the user interfaces and the data provided must be clear, meaningful and concise to accommodate users with different levels of computer skills.

• Extendable System Functionalities – the Event Server will be designed to allow easy addition of modules to extend the systems functionality.

3. System Architecture

3.1 System Overview

The purpose of the system is to provide a middleware solution for tracking and monitoring Assets within Residential Care Units and Individual Living Units by utilising RFID or similar technologies. The system consists of the following subsystems, shown in Figure 1 - System Architecture:

1. The Event Router contains the Data Collection Modules, the Event Messenger (Event Message Queue Client), and Local Event Database.

2. The Data Collection Module is an application built for a particular manufacture’s RFID hardware. Generally it is used to receive and parse the signals from a number of Readers into relevant data and then send it to the Local Event Database.

3. The Event Messenger is an application used for querying the Local Event Database and sending a message to the Event MQ if any Events are found.

4. The Event Server is the back-end system which comprises the Cisco IP Phone Connector and the logical components that process the Events being sent to the Event MQ into more detailed information about the condition of the Assets being tracked.

5. The Event MQ is the software used to provide messaging service for receiving Event messages from any remote Event Messenger and directs the received Events to the appropriate components of the Event Server.

6. The Asset Monitoring System (AMS) is the front-end system that the end users interact with. The main purpose is to display and report Events which have occurred, and the condition of the Assets to the users.

7. The Cisco IP Phone Connector is the software used to provide messaging services for the logical components to send message to a particular Cisco IP Phone.

Eve

nt

Se

rve

rE

ven

t R

ou

ter

Sequence of Wavetrend

RFID Readers

Wavetrend RFID Data Collection Module

Data Collector

Data Filter

AADL DB

Wi-Fi Data Collection Module

Data Collector

Data Filter

Wi-Fi Reader

Asset Monitoring SystemCisco IP Phone

Potentially Compatible

Asset Monitor

Administration

Search

Local Event DB

Event Messenger

Event MQ

Cisco IP Phone Connector

User Authentication

Positioning Access Control Alert Handling

Figure 1: System Architecture

Information is stored in a central database (AADL DB) and a temporary database (Local Event DB) within each Event Router, further described in Section 3.3 Database Design.

The system is also designed to interact with 3rd party systems such as VoIP (Voice over IP) telephones in order to provide additional services to staff. This functionality will be integrated into the system in Cycle 3 of the project.

3.2 Detailed Description

The Event Router contains one or more Data Collection Modules. Each Data Collection Module consists of a Data Collector and a Data Filter which are responsible for receiving data from their own Reader Network and for filtering out unnecessary Events. All Events that have been filtered by the Data Filter are then stored in a Local Event Database in the Event Router. By using a message queue service, Events are then processed on a first-in-first-out basis on both the client side (Event Router) and host side (Event Server). These Events will be sent from the client side and received by an Event message queue on the host which then will call the appropriate module to be processed. If the connection between the Event Router and Event Server is down, the Events will be retained in the Event Messenger’s MQ and sent automatically once the connection has been re-established.

The Event Router could potentially contain more than one Data Collection Module to accommodate the different tag and Reader Network platforms (e.g. Wavetrend and Aeroscout). Currently, the Data Collection Module for the Wavetrend hardware is written in Visual Basic 6.0.

The Event Server contains modules that perform processing of the Events from the Event MQ. For example, the Emergency Alert Event will be sent to the Alert Handling Module to make the updates to the relevant tables in the AADL Database. Other modules can be added to the Event Server to extend the system’s functionality.

Part of the functionality provided by the Asset Monitoring System (AMS) is a Graphical User Interface (GUI). The AMS will be used to monitor the Assets within the Reader Network and will communicate with AADL Database. The AMS will be able to display a list of the last 100 Events raised within the Reader Network. It will also be able to display a floor map of the Reader Network, where the Readers are and where the Tags are in that Network.

3.3 Database Design

A brief overview of each database used in the system is provided below. Database schemas are provided in Figure 2 – Database Schema, along with descriptions of each of the fields.

Local Event Database Stores Events which have been received from the RFID Reader Network.

AADL Database Stores information relating to Events, Tags, Readers, Networks, Assets, IP Phones, Maps

and Locations. Stores information relating to the end users/GUI such as login details and Alert

notification.

Events

PK,FK2 ReaderIDPK,FK1 TagIDPK EventOccurredTime

RSSIFK3 EventTypeIDFK4 NetworkID

Readers

PK ReaderID

FK1 NetworkIDFK2 ReaderTypeIDFK3 LocationID

EntryPointExitPoint

Tags

PK TagID

FK1 TagTypeIDActiveRegisteredLastSeenTime

FK2 LocationIDLocations

PK LocationID

LocationNameFK1 LocationTypeID

LocationDescription

Maps

PK MapID

MapImageWidthHeight

MapLocations

PK,FK1 MapIDPK,FK2 LocationID

MapLocationXMapLocationY

Alerts

PK AlertID

FK3 TagIDAlertTime

FK2 AlertTypeIDFK1 LastLocationID

AcknowledgementAckTime

FK4 AckByUsername

AlertTypes

PK AlertTypeID

FK1 CriticalLevelIDAlertTypeName

CriticalLevels

PK CriticalLevelID

CriticalLevelCriticalLevelName

Users

PK Username

UserPasswordFK1 UserClassID

JobPositionSessionID

UserClass

PK UserClassID

UserClassNameUserClassLevel

LocationTypes

PK LocationTypeID

LocationTypeName

EventTypes

PK EventTypeID

EventTypeName

AssetTypes

PK AssetTypeID

AssetTypeName

TagTypes

PK TagTypeID

TagTypeName

Networks

PK NetworkID

NetworkNameNetworkDescription

Assets

PK AssetID

AssetNameFK1 AssetTypeIDFK2 TagID

ReaderTypes

PK ReaderTypeID

ReaderTypeName

MapReaders

PK,FK2 MapIDPK,FK1 ReaderID

MapReaderXMapReaderY

IPPhones

PK IPPhoneID

IPAddressFK1 LocationID

IPPhoneDescription

Schedules

PK ScheduleID

FK1 AssetIDFK2 LocationID

StartAtStopAt

Timesheets

PK TimesheetID

FK1 AssetIDFK2 LocationID

RegTimeDirection

Privileges

PK,FK1 AssetIDPK,FK2 LocationID

Figure 2: Database Schema

(PK = Primary Key, FK = Foreign Key, Bold = Not Null, Red = New/Updated)

Common tables in Local Event Database and AADL Database

EventsReaderID The ID of the Reader that received the Event.TagID The ID of the Tag that raised the Event.EventOccurredTime The time the Event occurred.RSSI The signal strength of the Tag when the Event was raised.EventTypeID The type of Event that was raised.NetworkID The ID of the Network in which the Event was raised.

EventTypesEventTypeID An incremental ID representing the ID of an Event type.EventTypeName A textual name of the Event type.

AADL Database

AlertTypesAlertTypeID An incremental ID representing the ID of the Alert type.CriticalLevelID The ID representing how critical an Alert type is.AlertTypeName A textual description of the Alert type.

AlertsAlertID The ID of the Alert that was raised.TagID The ID of the Tag that raised the Alert.AlertTime Stores the time the Alert occurred.AlertTypeID The ID of the Alert type that occurred.LastLocationID The ID of the Location where the Alert occurred.Acknowledgment Used to represent whether an Alert was acknowledged or not.AckTime The time the Alert was acknowledged by a user.AckByUsername The User that acknowledged the Alert.

AssetTypesAssetTypeID An incremental ID representing the ID of the Asset.AssetTypeName A textual description of the Asset type e.g. elderly person, staff or

equipment.

AssetsAssetID An incremental ID representing the ID of the Asset.AssetName A textual description of the Asset.AssetTypeID The ID of the Asset type. Examples of Asset types are elderly person,

staff and equipment.TagID The ID of the Tag associated with this Asset.

CriticalLevelsCriticalLevelID An incremental ID representing the ID of the critical Level.CriticalLevel An integer used to represent how critical the critical level ID is.CriticalLevelName A textual description of the critical level.

IPPhonesIPPhoneID An incremental ID representing the ID of the IP Phone.IPAddress The IP address of the IP Phone.LocationID The LocationID the IP Phone is assigned to.IPPhoneDescription A textual description of the IP Phone.

LocationTypesLocationTypeID An incremental ID representing the ID of the Location type.LocationTypeName A textual description of a type of Location, eg. Bathrooms would all

have the same LocationTypeName.

LocationsLocationID An incremental ID representing the ID of a Location.LocationName A textual name of the Location, eg. FirstFloorKitchen.LocationTypeID An ID representing the type of Location, eg. Bathrooms would all

have the same LocationTypeID.LocationDescription Optional field to specify particular details about a Location.

MapLocationsMapID An incremental ID representing the ID of the map.LocationID An ID representing the ID of the Location the Map represents.MapLocationX Sets the X-coordinate of where a Location is on the Map in pixels.MapLocationY Sets the Y-coordinate of where a Location is on the Map in pixels.

MapReadersMapID An incremental ID representing the ID of the map.ReaderID An ID representing the ID of the Reader assigned to the Location.MapLocationX Sets the X-coordinate of where a Location is on the Map in pixels.MapLocationY Sets the Y-coordinate of where a Location is on the Map in pixels.

MapsMapID An incremental ID representing the ID of the map.MapImage A graphical map of a building, or section of a building.Width The width of the Map in pixels.Height The height of the Map in pixels.

NetworksNetworkID An ID representing the unique ID of a Network.NetworkName A name given to the Network.NetworkDescription A textual description of the Network.

Privileges (This table stores the access privileges of an Asset to a Location) AssetID The ID of the Asset.LocationID The ID of the Location.

ReaderTypesReaderTypeID An incremental ID representing the ID of the Reader type.ReaderTypeName A textual description of the Reader type.

ReadersReaderID An ID representing the unique ID of a Reader.NetworkID An ID representing the Network where the Reader is.ReaderTypeID An ID representing the type of Reader.LocationID An ID representing the Location of the Reader.EntryPoint A Boolean indicating whether the Reader is an Entry point.ExitPoint A Boolean indicating whether the Reader is an Exit point.

Schedules ScheduleID An incremental ID for each schedule.AssetID The ID of the Asset.LocationID The Location.StartAt The start time the Asset is assigned to be in charge of the Location.StopAt The end time the Asset is assigned to be in charge of the Location.

TagTypesTagTypeID An incremental ID representing the ID of the Tag type.TagTypeName A textual description of the Tag type e.g. Wavetrend Tags with duress

button and Wavetrend Tags with motion sensor reed switches.

TagsTagID The unique ID of a Tag.TagTypeID A textual description of the Tag type e.g. Wavetrend Tags with duress

button and Wavetrend Tags with motion sensor reed switches.LastSeenTime The last time the Tag raised an Event.LocationID The ID of the Location where the Tag was last detected.Active A Boolean which determines if a Tag is currently inside or outside the

facility.Registered A Boolean which determines the state of a Tag i.e. sets whether the

system should keep track of the Tag or not.

TimesheetsTimesheetID An incremental ID representing the ID of the Timesheet.AssetID The ID of the Asset.LocationID The ID of the Location the Asset was located.RegTime The time the Asset was detected.Direction A Boolean representing whether the Asset entered or left the Reader

Network.

UserClassUserClassID An incremental ID used to represent the user class ID.UserClassName A textual description of the user class.UserClassLevel An integer representing the level of the user class in the system.

UsersUsername A user’s identification name for the system.UserPassword A user’s password to gain access to the system.UserClassID An ID to represent the user’s class in the system.JobPosition A textual description of the user’s job position in the system.SessionID Authentication Session ID for users logged into the AMS.

3.4 Use Case Diagram

The following diagram describes how the main actors interact with the different components of the system. New/updated Use Cases and Actors are shown in pink.

<<inherits>>

Parse Event

Reader Network

AADL DB

Locate Tag

Event MQ

Handle Emergency Alert

User

Administrator

Event Router

Event Server

Asset Monitoring System

Login

Logout

Administrate Database

Search Assets

Display Event Log

Display Map Monitor

Local Event DB

Send MQ Message

Receive MQ Message

Check Access Privileges

Handle Lost Tag

Cisco IP Phone

Check-In

Check-Out

<<uses>>

<<uses>>

<<uses>>

<<uses>>

<<uses>>

<<uses>>

Send Phone Message

<<uses>>

Handle Low Battery Alert

Handle Motion Alert

<<uses>>

<<uses>>

Figure 3: Use Case Diagram

3.5 Use Case Scenarios and Sequence Diagrams

The following section describes the Use Case Scenarios needed to fulfil the requirements of the system for cycle 3 of the project. Sequence Diagrams have been provided for the non-trivial Use Cases.

3.4.1 Event Server

3.4.1.1 Positioning

Name: Locate TagGoal: To determine the last known Location of a TagPre Conditions: Tag is registeredPrimary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ receives an Event.2) The system looks up the LocationID from the ReaderID of the Event from the AADL

Database.3) The use case ends when the system updates the LastSeenTime as the EventOccurredTime

and the LocationID, to the relevant Tag in the Tags table of the AADL Database.

PositioningBean

handleMotionAlert(event)

find(Tag, event.getTagID())

tag

EventMQ em : EntityManager

find(Location, reader.getLocationID())

location

persist(tag)

find(Reader, event.getReaderID())

reader

tag.setLocationID(location.getLocationID())

tag.setLastSeenTime(event.getEventOccurredTime())

Figure 4: Locate Tag Sequence Diagram

3.4.1.2 Emergency Alert Handling

Name: Handle Emergency AlertGoal: To handle an OnTagAlarm Event and send an Emergency Alert to the AADL DatabasePre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ receives an OnTagAlarm Event.2) The system gets the LocationID of the relevant Tag from the Tags table of the AADL

Database.3) The system adds a new Alert Record, which updates the AlertTime as the

EventOccurredTime, AlertTypeID as ‘Emergency Call’, TagID and LocationID to the Alerts table of the AADL Database.

4) The system looks up the carer responsible for the Location the Event was raised in.5) The system finds the current Location of the carer and the IP Phone for that Location6) The use case ends when the system calls the CiscoIPPhoneConnector with the IP address

and the message.

AlertHandlingBean

handleEmergencyAlert(event)


tag


find(Asset, schedule.getAssetID())

asset

find(Location, tag.getLocationID())

location

alert.Alert<<create>>

persist(alert)

find(Schedule, location.getLocationID(), event.getEventOccurredTime())

schedule <List>

CiscoIPPhoneConnector

sendMessage(ipPhone,message)

find(Tag, asset.getTagID())

tag

find(IpPhone, tag.getLocationID())

ipPhone <List>

Figure 5: Handle Emergency Alert Sequence Diagram

3.4.1.3 Low Battery Alert Handling

Name: Handle Low Battery AlertGoal: To handle OnTagBattAlarm Event and send a Low Battery Alert to the AADL DatabasePre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ received an OnTagBattAlarm Event.2) The system gets the LocationID of the relevant Tag from the Tags table of the AADL

Database.3) The use case ends when the system adds a new Alert Record, which includes

EventOccurredTime to AlertTime, Low Battery as AlertTypeID, TagID and LocationID to the Alerts table of the AADL Database.

AlertHandlingBean

handleLowBatteryAlert(event)


tag



location

alert : Alert<<create>>

persist(alert)

Figure 6: Handle Emergency Low Battery Sequence Diagram

3.4.1.4 Motion Alert Handling

Name: Handle Motion AlertGoal: To handle OnTagMovCount Event and send a Motion Alert to the AADL DatabasePre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ received an OnTagMovCount Event.2) The system gets the LocationID of the relevant Tag from the Tags table of the AADL

Database.3) The use case ends when the system adds a new Alert Record, which includes

EventOccurredTime to AlertTime, Motion Alert as AlertTypeID, TagID and LastLocationID to the Alerts table of the AADL Database.

AlertHandlingBean

handleMotionAlert(event)


tag



location


persist(alert)

Figure 7: Handle Motion Alert Sequence Diagram

3.4.1.5 Check-In

Name: Check-InGoal: To detect and log when a Tag enters an Entry-point ReaderPre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ received an OnNewTag Event.2) The system will then check if the Reader that detected this Event is a specified Entry Point

Reader.3) The system then checks the Tags table to decide whether the Tag was previously not active

inside the facility.4) The system will then update the Tag to currently being active in the system.5) The use case ends when the system records the time the Event occurred, AssetID,

LocationID, and in-direction.

Extensions2a)The use case ends when the system has detected the Reader is not an Entry Point Reader.3a) The use case ends when the system has detected the Tag is active.

AccessControlBean

checkIn(event)


reader



tag

persist(tag)


location

find(Asset, tag.getAssetID())

asset

tag.setActive(true)

timesheet : Timesheet<<create>>

persist(timesheet)

Figure 8: Check-In Sequence Diagram

3.4.1.6 Check-Out

Name: Check-OutGoal: To detect and log when a Tag leaves an Exit-point ReaderPre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ received an OnTagTimeout Event2) The system will then check if the Reader that detected this Event is a specified Exit Point

Reader.3) The system then checks the Tags table to decide wether the Tag was previously active

inside the facility.4) The system will then update the Tag to currently being outside the system.5) The use case ends when the system records the time the Event occurred, AssetID,

LocationID, and out-direction.

Extensions2a)The use case ends when the system has detected the Reader is not aa Exit Point Reader.3a) The use case ends when the system has detected the Tag is not active.

AccessControlBean

checkOut(event)


reader



tag

persist(tag)


location

find(Asset, tag.getAssetID())

asset

tag.setActive(false)

timesheet : Timesheet<<create>>

persist(timesheet)

Figure 9: Check-Out Sequence Diagram

3.4.1.7 Handle Lost Tag

Name: Handle Lost TagGoal: To detect when a Tag timeouts and did not leave through the specified Exit Point ReadersPre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ received an OnTagTimeout Event.2) The system will then check if the Reader that detected this Event is not a specified Exit Point

Reader.3) The system then checks the Tags table to decide whether the Tag was previously active

inside the Reader Network4) The use case ends when the system creates an Alert with the LocationID and AssetID of the

lost Tag.

Extensions2a)The use case ends when the system has detected the Reader is a Exit Point Reader.3a)The use case ends when the system has detected the Tag is not active.

AccessControlBean

handleLostTag(event)


reader



tag


location


persist(alert)

Figure 10: Handle Lost Tag Sequence Diagram

3.4.1.8 Check Access Privileges

Name: Check Access PrivilegesGoal: To detect when a Tag has entered a Location that the Tag is not allowed to, and produce an Alert.Pre Conditions: Tag which raised the Event is registered.Primary Actor: Event MQ

Main Success Scenario:1) The use case begins when the Event MQ received an OnTagMovedReader Event.2) The system will then check the current LocationID of the Tag and AssetID against the

Location privileges that the Asset is not allowed to enter.3) The use case ends when the system creates an Alert with the LocationID and AssetID of the

offending Tag.

Extensions2a)The use case ends when the system has detected the Asset is allowed to enter the

Location.

AccessControlBean

checkAccessPrivileges (event)


tag


find(Asset, tag.getTagID())

asset

persist(tag)


location


asset


Figure 11: Check Access Privileges Sequence Diagram

3.4.1.9 Cisco IP Phone Connector

Name: Send Phone MessageGoal: To send a SOAP Envelope to the specified Cisco IP PhonePre Conditions: Specified IP address and Message

Main Success Scenario:1) The use case begins when the system called CiscoIPPhoneConnector with an IP address

and a message as parameters.2) The system will then create a SOAP Envelope for Cisco IP Phone and add the message into

the envelope.3) The system initiates the URL using the IP address and the Cisco Message Centre.4) The system sends the SOAP Envelope to the URL.5) The use case ends when the system does not receive any error when sending the SOAP

Envelope.

Extensions5a)The use case ends when the system receive error(s) while sending the SOAP Envelope.

Sequence Diagram???

aadl c3 sds.doc

Business