• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
AADL C3 SDS.doc
 

AADL C3 SDS.doc

on

  • 354 views

 

Statistics

Views

Total Views
354
Views on SlideShare
354
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    AADL C3 SDS.doc AADL C3 SDS.doc Document Transcript

    • RFID Aged and Assisted Digital Living Project Curtin University of Technology Software Design Specification Version 3.0 (Draft) Last Updated: 24th October 2006 Page 1
    • Revision History Name Date Reason for Changes Version AADL 17/05/2006 Initial version 1.0 AADL 20/05/2006 1st Inspection 1.1 AADL 21/05/2006 Test Provisions Section Added 1.2 AADL 22/05/2006 2nd Inspection 1.3 AADL 23/08/2006 Cycle 2 Design Specification 2.0 Draft AADL 2/09/2006 Cycle 2 Inspection 2.0 AADL 24/10/2006 Cycle 3 Design Specification 3.0 Draft Page 2
    • 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 Page 3
    • 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 Page 4
    • 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. Page 5
    • 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. Page 6
    • Potentially Sequence of Compatible Wavetrend Wi-Fi Reader RFID Readers Wavetrend RFID Wi-Fi Event Router Data Collection Module Data Collection Module Local Data Event DB Data Data Filter Data Filter Collector Collector Event Messenger Event MQ Event Server Positioning Access Control Alert Handling Cisco IP Phone Connector AADL DB Asset Monitoring System Cisco IP Phone User Authentication Administration Asset Monitor Search 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. Page 7
    • 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. Page 8
    • Events EventTypes PK,FK2 ReaderID PK EventTypeID PK,FK1 TagID PK EventOccurredTime EventTypeName RSSI FK3 EventTypeID FK4 NetworkID Tags Networks ReaderTypes Readers PK TagID TagTypes PK NetworkID PK ReaderTypeID PK ReaderID AssetTypes FK1 TagTypeID PK TagTypeID NetworkName ReaderTypeName Active FK1 NetworkID NetworkDescription PK AssetTypeID Registered TagTypeName FK2 ReaderTypeID LastSeenTime FK3 LocationID AssetTypeName FK2 LocationID EntryPoint ExitPoint MapReaders Locations PK,FK2 MapID PK LocationID PK,FK1 ReaderID Privileges Assets LocationName IPPhones PK,FK1 AssetID MapReaderX PK,FK2 LocationID FK1 LocationTypeID MapReaderY PK AssetID LocationDescription PK IPPhoneID AssetName IPAddress FK1 AssetTypeID FK1 LocationID FK2 TagID IPPhoneDescription Timesheets PK TimesheetID Maps Schedules MapLocations FK1 AssetID LocationTypes PK MapID PK ScheduleID FK2 LocationID PK,FK1 MapID RegTime PK LocationTypeID PK,FK2 LocationID MapImage FK1 AssetID Direction Width FK2 LocationID LocationTypeName MapLocationX Height StartAt MapLocationY StopAt Alerts PK AlertID AlertTypes CriticalLevels FK3 TagID AlertTime PK AlertTypeID PK CriticalLevelID Users FK2 AlertTypeID UserClass FK1 LastLocationID FK1 CriticalLevelID CriticalLevel PK Username Acknowledgement PK UserClassID AlertTypeName CriticalLevelName AckTime UserPassword FK4 AckByUsername FK1 UserClassID UserClassName JobPosition UserClassLevel SessionID Figure 2: Database Schema (PK = Primary Key, FK = Foreign Key, Bold = Not Null, Red = New/Updated) Page 9
    • Common tables in Local Event Database and AADL Database Events ReaderID 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. EventTypes EventTypeID An incremental ID representing the ID of an Event type. EventTypeName A textual name of the Event type. AADL Database AlertTypes AlertTypeID 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. Alerts AlertID 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. AssetTypes AssetTypeID An incremental ID representing the ID of the Asset. AssetTypeName A textual description of the Asset type e.g. elderly person, staff or equipment. Assets AssetID 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. Page 10
    • CriticalLevels CriticalLevelID 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. IPPhones IPPhoneID 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. LocationTypes LocationTypeID 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. Locations LocationID 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. MapLocations MapID 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. MapReaders MapID 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. Maps MapID 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. Networks NetworkID 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. Page 11
    • ReaderTypes ReaderTypeID An incremental ID representing the ID of the Reader type. ReaderTypeName A textual description of the Reader type. Readers ReaderID 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. TagTypes TagTypeID 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. Tags TagID 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. Timesheets TimesheetID 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. UserClass UserClassID 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. Page 12
    • Users Username 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. Page 13
    • 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. Event Router Parse Event Send MQ Message Reader Network Local Event DB Event Server <<uses>> Handle Emergency Alert Receive MQ Message <<uses>> Event MQ <<uses>> <<uses>> Handle Low Battery Alert <<uses>> <<uses>> <<uses>> Send Phone Message <<uses>> <<uses>> Handle Motion Alert Locate Tag Cisco IP Phone Check-In Handle Lost Tag Check-Out Check Access Privileges AADL DB Asset Monitoring System Display Event Log Search Assets User Display Map Monitor <<inherits>> Login Logout Administrate Database Administrator Figure 3: Use Case Diagram Page 14
    • 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 Tag Goal: To determine the last known Location of a Tag Pre Conditions: Tag is registered Primary 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. Page 15
    • EventMQ PositioningBean em : EntityManager handleMotionAlert(event) find(Tag, event.getTagID()) tag find(Reader, event.getReaderID()) reader find(Location, reader.getLocationID()) location tag.setLocationID(location.getLocationID()) tag.setLastSeenTime(event.getEventOccurredTime()) persist(tag) Figure 4: Locate Tag Sequence Diagram Page 16
    • 3.4.1.2 Emergency Alert Handling Name: Handle Emergency Alert Goal: To handle an OnTagAlarm Event and send an Emergency Alert to the AADL Database 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 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 Location 6) The use case ends when the system calls the CiscoIPPhoneConnector with the IP address and the message. Page 17
    • EventMQ AlertHandlingBean em : EntityManager CiscoIPPhoneConnector handleEmergencyAlert(event) find(Tag, event.getTagID()) tag find(Location, tag.getLocationID()) location <<create>> alert.Alert persist(alert) find(Schedule, location.getLocationID(), event.getEventOccurredTime()) schedule <List> find(Asset, schedule.getAssetID()) asset find(Tag, asset.getTagID()) tag find(IpPhone, tag.getLocationID()) ipPhone <List> sendMessage(ipPhone,message) Figure 5: Handle Emergency Alert Sequence Diagram Page 18
    • 3.4.1.3 Low Battery Alert Handling Name: Handle Low Battery Alert Goal: To handle OnTagBattAlarm Event and send a Low Battery Alert to the AADL Database 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 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. EventMQ AlertHandlingBean em : EntityManager handleLowBatteryAlert(event) find(Tag, event.getTagID()) tag find(Location, tag.getLocationID()) location <<create>> alert : Alert persist(alert) Figure 6: Handle Emergency Low Battery Sequence Diagram Page 19
    • 3.4.1.4 Motion Alert Handling Name: Handle Motion Alert Goal: To handle OnTagMovCount Event and send a Motion Alert to the AADL Database 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 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. EventMQ AlertHandlingBean em : EntityManager handleMotionAlert(event) find(Tag, event.getTagID()) tag find(Location, tag.getLocationID()) location <<create>> alert : Alert persist(alert) Figure 7: Handle Motion Alert Sequence Diagram Page 20
    • 3.4.1.5 Check-In Name: Check-In Goal: To detect and log when a Tag enters an Entry-point Reader 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 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. Extensions 2a) 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. Page 21
    • EventMQ AccessControlBean em : EntityManager checkIn(event) find(Reader, event.getReaderID()) reader find(Tag, event.getTagID()) tag tag.setActive(true) persist(tag) find(Location, reader.getLocationID()) location find(Asset, tag.getAssetID()) asset <<create>> timesheet : Timesheet persist(timesheet) Figure 8: Check-In Sequence Diagram Page 22
    • 3.4.1.6 Check-Out Name: Check-Out Goal: To detect and log when a Tag leaves an Exit-point Reader 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 OnTagTimeout Event 2) 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. Extensions 2a) 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. Page 23
    • EventMQ AccessControlBean em : EntityManager checkOut(event) find(Reader, event.getReaderID()) reader find(Tag, event.getTagID()) tag tag.setActive(false) persist(tag) find(Location, reader.getLocationID()) location find(Asset, tag.getAssetID()) asset <<create>> timesheet : Timesheet persist(timesheet) Figure 9: Check-Out Sequence Diagram Page 24
    • 3.4.1.7 Handle Lost Tag Name: Handle Lost Tag Goal: To detect when a Tag timeouts and did not leave through the specified Exit Point Readers 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 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 Network 4) The use case ends when the system creates an Alert with the LocationID and AssetID of the lost Tag. Extensions 2a) 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. EventMQ AccessControlBean em : EntityManager handleLostTag(event) find(Reader, event.getReaderID()) reader find(Tag, event.getTagID()) tag find(Location, reader.getLocationID()) location <<create>> alert : Alert persist(alert) Page 25
    • Figure 10: Handle Lost Tag Sequence Diagram Page 26
    • 3.4.1.8 Check Access Privileges Name: Check Access Privileges Goal: 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. Extensions 2a) The use case ends when the system has detected the Asset is allowed to enter the Location. EventMQ AccessControlBean em : EntityManager checkAccessPrivileges (event) find(Tag, event.getTagID()) tag find(Asset, tag.getTagID()) asset find(Reader, event.getReaderID()) asset find(Location, reader.getLocationID()) location <<create>> alert : Alert persist(tag) Figure 11: Check Access Privileges Sequence Diagram Page 27
    • 3.4.1.9 Cisco IP Phone Connector Name: Send Phone Message Goal: To send a SOAP Envelope to the specified Cisco IP Phone Pre 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. Extensions 5a) The use case ends when the system receive error(s) while sending the SOAP Envelope. Sequence Diagram??? Page 28