Gold Team - Arcom Luggage Control System / Date: 10/25/07
ArcomLuggageControl System
Software Requirements Specification
Version 1.0
Gold Team
SE545[CC1] – Fall 2007 – 10/25/07
Jesse Berger
Cory Carson
Raja Chinthakuntla
Jay Dow
Kenneth Evensen
Table of Contents
1 Introduction
1.1 Purpose
1.2 Scope
1.3 Acronyms & Definitions
1.3.1 Acronyms
1.3.2 Definitions
1.4 References
2 Overall Description
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 User Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.2 Product Functions
2.2.1 User Characteristics
2.2.2 Constraints
2.3 Assumptions and Dependencies
3 Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communication Requirements
3.2 Functional Requirements
3.2.1 Performance Requirements
3.2.2 Design Requirements
3.3 Event-Response List
4 Appendices
4.1 Use Case Diagram
4.2 Use Cases
Use Case 1 – Add Package
Use Case 2 – Pick Up Package
Use Case 3 – View Package Log
Use Case 4 – Initiate Manual Control
Use Case 6 – User Views System Status
Use Case 7 - Slow pickup (“Traffic Jam”)
Use case 8 Vanishing package, belt 1
Use case 9 Vanishing package, belt 2
Revision History
Version / Date / Changes0.1 / 9/21/07 / Formatting created
0.2 / 9/25/07 / Formatting completed, major content update.
0.3 / 10/5/07 / Fixed issues found in collective team peer reviews.
0.4 / 10/8/07 / Corrected minor details, formatting, and added minor content
0.5 / 10/9/07 / Added system diagram, additional use cases and corrected grammar.
0.6 / 10/24/07 / Correct items noted during peer review.
0.7 / 10/24/07 / Requirement fixes, Use case Seq Diag.
0.8 / 10/25/07 / Use Case fixes, final fixes, ER list
1.0 / 10/25/07 / Release Document Created
1 Introduction
1.1 Purpose
This document describes a simulation of a Luggage Control System for demonstration to the customer of the feasibility of a full-scale product. The simulation is denoted by Arcom Luggage Control System. [CC2]
1.2 Scope
This document describes requirements for software and hardware functionality of the Arcom Luggage Control System. This document does not discuss licensing, security, or safety precautions that would be part of the full product requirements, nor does it discuss costs.[CC3]
1.3 Acronyms & Definitions
1.3.1 Acronyms
ALC System, ALCS – Arcom Luggage Control System
RS-232 – Recommended Standard 232. Used as a standard for serial port communication.
1.3.2Definitions[CC4]
Arcom – Brand of embedded systems.
Arcom Box – An Arcom SBC-GX1 component. Includes a 300MHz AMD Geode processor, VGA output, and an Ethernet adapter.
GoAhead Web Server – An embedded web server.
Deviations –Events that differ from standard operation, including item blockage and sensor failures.
Fischertechnik – Brand of rapid prototyping blocks.
Robo-Interface – A Fischertechnik provided control block for motors and sensors.
WindRiver – Brand of embedded platforms
VxWorks – A real-time operating system and development platform produced by WindRiver.
Scanner –A physical mockup of an active luggage scanner.
Pusher – A waldo mechanism to move packages from LOC4 to LOC5.
LOC1 – The area in which packages are placed by users. This area detects packages.
LOC2 – The area between LOC1 and the LOC3
LOC3 – The area before the scanning area. This area detects packages.
LOC4 – The area where the scanner scans a package.
LOC5 – The area where the pusher pushes packages from LOC4 to. This is immediately adjacent to LOC4.
LOC6 – The area between LOC5 and LOC7
LOC7 – The area where packages are picked up by users.
Normal Operation – The normal passage and scanning of packages by the system.
Manual Operation – System operates according to direct user commands.
1.4 References
SE545 Project System Description Document
Sample SRS for format
WindRiver VxWorks 5.4 Reference Manual
2 Overall Description
2.1 Product Perspective
The Arcom Luggage Control System is a functioning model using Fischertechnik Construction Blocks. The model is comprised of two conveyer belts, joined in an “L” shape. Each belt is driven by a dedicated motor, a vertical “scanner” driven by a third motor and a pusher device by a fourth. An object travels along the first belt, is “scanned” and then is moved onto the second belt by the “Pusher”. The purpose is to simulate a full-scale luggage conveyor system deployed in many airports.
The system also includes a user-web interface provided by a GoAhead web server. This interface shall display model status errors and log normal operation.
2.1.1 System Interfaces
The interface between the Arcom Box and the Fischertechnik Model is provided by the Fischertechnik 93293 Robo-Interface Board; the board shall provide an RS-232 connection for the Arcom Box
2.1.2 User Interfaces
The user interface shall be presented as a web page, giving cross-platform support with little extra effort. Among other items, itshall display:
- Each processed item having a unique identifier and timestamp appended to the top of the item archive.
- Existing or recent deviations
2.1.3 Hardware Interfaces
The Fischertechnik Robo-Interface Board accepts communications via an RS-232 Serial Link and interprets data in order to drive the motors and read the sensors attached to the Robo-Interface Board. The RS-232 Serial Link is attached to the Arcom.
2.1.4 Software Interfaces
The software developed for the ALCS shall run on WindRiver's VxWorks operating system. The VxWorks operating system provides an ideal platform to run time critical software. It provides all required facilities to implement a real-time system. The user interface shall be platform independent and run inside any standard web-browser.
2.2 Product Functions
2.2.1 User Characteristics
Users of this system shall interact via the user interface located at a specified web address hosted via the GoAhead web server. This interface shall provide capability to remotely and manually control the system and receive information on system status and performance.
The users of the system shall also be familiar with the operation of the hardware system. They shall also be familiar with a web-interface for the purposes of monitoring the system. In the event of a physical system failure (i.e. blocked sensor) the user shall know how to resolve the physical issue and restart the system.[CC5]
2.2.2 Constraints
CO1.) The system shall be developed using WindView Tornado.
CO2.) The system shall run within a VxWorks OS.
CO3.) The software shall be implemented in the C language.
CO4.) The system shall be developed with TSP-style deliverables.
CO5.) The project deliverable deadlines shall not be extended.[CC6]
2.3 Assumptions and Dependencies
AS1.) The user of the system shall be familiar with the operation of the hardware system.
AS2.) The user shall also be familiar with a web-interface for the purposes of monitoring the system.
AS3.) In the event of a physical system failure (i.e. blocked sensor) the user shall know how to resolve the physical issue and restart the system.[CC7]
3 Requirements[CC8]
3.1 External Interface Requirements
3.1.1 User Interfaces
SD1.) The system shall utilize a web site to provide a user interface.[CC9]
SD20.)Removed[CC10].
SD23.)The web interface shall provide a manual control page containing
SD23.1) Deviation status.
SD23.2) Sensor states for all sensors
SD23.3) Motor states for all motors.
SD23.4) Motor control for all motors.
SD23.5) A method of returning to automatic operation.
SD4.) The webinterface shall provide a main view page containing[CC11]
SD4.1) Deviation status.
SD4.2) System Uptime.
SD4.3) Number of packages scanned.
SD4.4) Notification of package waiting at LOC7.
SD2.) The webinterface shall provide a package page containing[CC12]
SD2.1) Timestamps of packages scanned.
SD2.2) Serial numbers of packages scanned.
SD5.) Removed.[CC13][CC14]
SF4.) The web interface shall provide a method of shutting the system down.
3.1.2 Hardware Interfaces
SD7.) The Arcom shall sense the state of the system from Fischertechnik
SD7.1) Light sensors.
SD7.2) Touch sensors.
SD7.3) Motor states..
SD6.) Removed[CC15].
SD8.) Removed.[CC16]
SD12.) The Fischertechnik motors and sensors shall be operated by the Fischertechnik Robo-Interface (p/n 93293).
SD11.) The system shall have accommodations for one (1) extra sensor.[CC17]
3.1.3 Software Interfaces
SD13.) The software shall run on the Arcom in the VxWorks real-time operating system.
SD14.) The web server shall run on the Arcom served by a GoAhead web server.
SD22.) Removed.[CC18][CC19]
3.1.4 Communication Requirements
SD15.) The Robo-Interface shall communicate with the Arcom via an RS-232 connector.
SD16.) The Arcom shall communicate with the Robo-Interface at a baud rate of 9600 bps, no parity, and one stop bit.
SD17.) The Arcom shall serve the web page via a local area network connection on the Ethernet adapter. [CC20]
SF1.) The system shall display all detected [CC21]deviations from normal operation to the user
SF1.1) Possible sensor failure.
SF1.2) Possible motor failure.
SF1.3) Possible missing package.
SD1.4) Loss of connection to Robo-Interface.
SD1.5) Other errors as necessary from product design.
3.2 Functional Requirements
SD10.) The system shall begin normal operations upon power on without human interaction.
SD3.) The system shall archive each package scanned with a serial number and time stamp.
ST1.) The system shall engage the scanner 2 seconds after a package reaches LOC4.
ST2.) The scanner shall remain in the down, scanning position, for 10 seconds.
ST3.) If the scanner is in the up position and LOC5 is empty, the Pusher shall immediately [CC22]move the package from LOC4 to LOC5.
SF3.)Removed[CC23].
SD18.) The system shall store information about packages scanned
SD18.1) Timestamp of scanning.
SD18.2) Serial number of package.
SD19.) Scanned package information shall be stored in volatile memory.[CC24]
SF5.) System shall handle packages which are removed from the system before they reach the next sensor.[KE25]
3.2.1 Performance Requirements[CC26]
No performance requirements specified.
3.2.2 Design Requirements
SD9.) The Robo-Interface defaults to direct control mode upon startup when the RS-232 interface is utilized.
SF2.) A package shall be known in LOC4 if it arrives in LOC3 and is moved beyond LOC3.
SD21.) The system software shall be implemented in VxWorks executing on an Arcom box.[CC27]
3.3 Sensor-Response Table
Trip: Package detected
Clear: No package
D/C: State ignored
LocationState / System ResponseLOC1 / LOC3 / LOC4 / LOC5 / LOC7
Clear / Clear / D/C / D/C / D/C / Do not change belt 1 state
Trip / Clear / D/C / D/C / D/C / Belt 1 activated
D/C / Trip / Clear / D/C / D/C / Belt 1 activate until LOC3 is clear
D/C / Trip / Occupied / D/C / D/C / Belt 1 disabled
D/C / D/C / Occupied / Clear / D/C / Scan package if not already scanned, push package to LOC5
D/C / D/C / Occupied / Occupied / D/C / Scan package
D/C / D/C / D/C / Clear / Clear / Do not change belt 2 state
D/C / D/C / D/C / D/C / Trip / Belt 2 disabled
D/C / D/C / D/C / Occupied / Clear / Belt 2 activated
4 Appendices
4.1 Use Case Diagram
Figure 1. Use Case Diagram. – This denotes a selection of nominal functionality use cases.
4.2 Use Cases
Use Case 1 – Add Package
Primary Actors: User
Secondary Actors: Hardware system
Mode(s): Normal
Preconditions: The hardware system is powered on and online
User is in physical location of hardware system
There is no package in the LOC1
Post conditions: Package moved to LOC4
Requirements Addressed: SF2
User Action / System Action1 / User places a package in the LOC1
1 / The system senses the package at LOC1.
2 / System checksLOC3 to determine if it is clear.
3 / When LOC3 is clear, the system moves the package to the LOC3.
Use Case 2 – Pick Up Package
Primary Actors: User
Secondary Actors: Hardware system
Mode(s): Normal
Preconditions: The hardware system is powered on and online
User is in physical location of hardware system
There is a package in the LOC4
Post conditions: Package processed
Package removed from LOC7
Requirements Addressed:ST3
User Action / System Action1 / System checks to see if the LOC7 is clear.
2 / System operates the Pusher to move package from LOC4 to LOC5
3 / Move package along belt from LOC5 to LOC7
1 / User removes Package
Use Case 3 – View Package Log
Primary Actors: User
Secondary Actors: Hardware system
Mode(s): Normal
Preconditions: The hardware system is powered on and online
There is package data stored in the archive.
Post Conditions:Package archive data displayed
Requirements Addressed: SD2, SD4, SD14
User Action / System Action1 / User enters URL to access system.
2 / User clicks on the View Archive Data
3 / System responds by displaying all package archive data to the display
Use Case 4 –Initiate Manual Control
Primary Actors: User
Secondary Actors: User Interface, Hardware system
Mode(s):Manual
Preconditions: The hardware system is powered on and online
User is in physical location of hardware system
User is familiar with hardware system operations and operates hardware system successfully
Post Conditions:Hardware resumes automated operation
Requirements Addressed: SD23, SF4
User Action / System Action1 / User enters URL to access system.
1 / Interface reports status of hardware system
2 / User selects manual control of hardware system
2 / Interface reports hardware system is under manual control
3 / Interface presents user controls for all systems and sensor data for all sensors
3 / User places package in LOC1 and begins operating hardware system via user interface
4 / Responds according to manual control input
4 / Upon successful transition of the package to LOC7, User removes package
5 / User disables manual control
5 / Hardware system resumes automated operation, waiting for package to appear in LOC1
[JB28]
Use Case 6 – User Views System Status
Primary Actors: User
Secondary Actors: Hardware system
Mode(s): Normal
Preconditions: The hardware system is powered on and online
User is in physical location of hardware system
User is familiar with hardware system operations and operates hardware system successfully
Post conditions:Motor and sensor status displayed in graphical user interface
Requirements Addressed: SD2, SD4
User Action / System Action1 / User enters URL to access system.
1 / System displays main interface with motor/sensor status[JB29]
Use Case 7 - Slow pickup (“Traffic Jam”)
Primary Actors: Hardware system
Secondary Actors: User
Mode(s): Normal
Preconditions: Hardware system is empty of packages.
The rate at which packages are provided momentarily exceeds the rate at which they
are picked up.
Post conditions:System resumes normal operation
Requirements Addressed: ST3
User Action / System Action1 / User places package 1 in LOC1
1 / Hardware system begins moving package 1 to LOC4
2 / User places package 2 in LOC1
2 / Hardware system waits for package 1 to leave LOC4 before moving package 2 to LOC4
3 / User places package 3 in LOC1
3 / Hardware system moves package 1 to LOC7
4 / Hardware systemdelays moving package 2 out of LOC5 due to package 1 being in LOC7.
5 / Hardware systemdelays moving package 3 to LOC5 due to package 2 being in LOC5
4 / User removes package 1 from LOC7
6 / Hardware systemactivates pusher and moves package 2 through the LOC4 to theLOC5
7 / Hardware systemactivates belt 2 and moves package 3to the LOC7
Use case 8 Vanishing package, belt 1
Primary Actors: Hardware system
Modes: Normal/Manual
Secondary Actors: Interface, User
Preconditions: An extraction is arranged for a package on belt 1
Post conditions:System resumes normal operation
Requirements Addressed: SF5
1 / User places package in LOC11 / Hardware system moves package toward LOC4
2 / Package 1 is removed before it reaches LOC4
2 / After user specified amount of time system checks belt 1 functionality. If system reports belt 1 operating normally the interface records package serial number, no time stamp, and indicates package did not reach LOC4.
Use case 9 Vanishing package, belt 2
Primary Actors: Hardware system
Secondary Actors: Interface, User
Modes: Normal/Manual
Preconditions: An extraction is arranged for a package on belt 2
Post conditions:System resumes normal operation
Requirements Addressed: SF5
User Action / System Action1 / User places package in LOC1
1 / Hardware system moves package toward LOC4
2 / Hardware system scans package at LOC4 and begins moving package to LOC7
2 / Package is removed before reaching LOC7
3 / After specified amount of time system checks belt 2 functionality. If system reports belt 2 operating normally the interface records package serial number, time stamp, and indicates package was removed.
ERAU - SE545 – 2007FAPage 1 of 25
[CC1]Adjusted the header to the new name of the system
[CC2]More accurate document purpose
[CC3]More accurate scope of the document.
[CC4]Now with more beef.
[CC5]Formatting fix
[CC6]Requirement fixes – ambiguity, weak wording, etc.
[CC7]Formatting fix. This was marked at Heading 1, and would show up in the table of contents
[CC8]These have been massively reorganized and rewritten. We even had a few duplicate requirements.
[CC9]Clarification
[CC10]Duplicate of SD1
[CC11]Fleshed out
[CC12]Fleshed out
[CC13]“The user interface web page shall allow normal operation of each function.” I don’t even know what this is trying to say…
[CC14]“The user interface web page shall allow normal operation of each function.” I don’t even know what this is trying to say…
[CC15]Compound, unclear, and duplicates of SD21 and SD15
[CC16]“The Arcom shall read one sensor per Robo-Interface specification, eg. one sensor per function” is unnecessarily restrictive. If anything, this might be design.
[CC17]Are we absolutely sure this is the case? It could cause lots of difficulty later for us.
Clarity fix
[CC18]If the only user control is remotely through the webpage, how do they get it back? This is bad. Very bad.
[CC19]If the only user control is remotely through the webpage, how
[CC20]Compound requirement; wording fix.
[CC21]Fleshed out
[CC22]5 seconds was wholly unnecessary.
[CC23]Duplicate of ST3
[CC24]Updated wording; non-volatile is not the same thing as volatile, and we meant volatile.
[KE25]Added to satisfy use cases 8 and 9
[CC26]None of the requirements listed here really were performance requirements.
[CC27]More specific.
[JB28]Use Case 5 is deleted
[JB29]Display? Ahhhh!