SerTi

Susanna Blomqvist
Antti Korhonen
Heikki Mylläri
Pekka Pakari

						Requirement specification 0.1
						19.2.2003

University of Jyväskylä
Department of Mathematical Information Technology

Authors: 	Susanna Blomqvist (SB), Antti Korhonen (AK), Heikki Mylläri (HM) ja Pekka Pakari (PP)
Työ: 		Requirement specification for software project
Abstract:	… 

Version history:

Version	Date		Description	
0.1	20.02.2003	PP, SB		
				Table 1 Version history

Table of Contents

1.	Introduction
2.	Terms, Acronyms and Abbreviations
3.	Description of System
4.	Requirements and Constraints 
4.1 Functional Requirements
4.2 Non-Functional Requirements
4.3 Implementation Requirements
4.4 Constraints 
5.	Use Cases
5.1 Initialization
5.2 Set and send configuration 
5.3 Retrieving status
5.4 Running motors
5.5 Logging 

1. Introduction

This document describes the requirements of SerialTester software that will be developed by SerTi project. The project is organized by the Department of Mathematical Information Technology in the University of Jyväskylä and the customer is Stresstech Ltd.
The main idea of SerialTester is to test and monitor equipment controlled via RS232 line (serial port). The software is especially used for Stress Logic that is a logical motor driver and I/O board manufactured by Stresstech Ltd. As at this moment all testing is made by hand using HyperTerminal, SerialTester should make the configuring and testing of the system a lot easier.
[Appendix 1: SerialTester General Specification, Ilkka Urtamo 13.12.2002.]

2. Terms, Acronyms and Abbreviations

Some terms that are used in this document:

SL	StressLogic. Motor driver and I/O board manufactured by StressTech Oy	
ST	SerialTester	
RS232	PC serial communication standard	
I/O	Input/Output	
SpyCable	Special, 3 headed cable used to monitor RS232 communication between two systems. Third end is connected to PC running program that “logs” the messages passet between the monitored systems.	
GUI	Graphical user interface	
View/Model	Designing concept where model (core where functionality is) is separated from View (GUI). This means there is no real functionality is GUI classes.	
[Appendix 1]

3. Description of system

Figure 1

The following picture represents the StressLogic’s environment of use. The SerialTester program is running in the figure’s computer that is connected to StressLogic with a serial cable. Notify that StressLogic is able to control 1 to 3 motor(s).

4. Requirements and constraints

4.1 Functional requirements

•	Connect and initialize StressLogic
The program runs command IN to initialize the SL and tells whether there is errors or not.
•	Send all motor parameters to StressLogic with one user command
Motor parameters are saved in a file, and user can then easily send them all together to SL which sends parameters on to specific motor and reads the results and sends them back to ST.
•	User can select all RS232 port settings
You can change the settings of serial port, like speed and choose the port…
•	Store port settings for next use
When you close the program are all currently used settings are saved so that when you next time start the ST you don’t have to set them again.
•	Retrieve motor and i/o status of the StressLogic and view it in human readable way
When using commands like “MLm”[Appendix 2] StressLogic gives as response something mystical parameters including hexanumbers. SerialTester shows this information so that it is easy to read and understand.
•	User can run motor reference prosedure
•	User can run motors by selecting motor, target position and command running
•	User can set motor and i/o parameters
•	User can save/load motor and i/o parameters
•	User can send raw text commands to port
There is an edit line where user can manually write commands and then send them to StressLogic, like using HyperTerminal.
•	User can use 'copy' from log screen
•	User can use 'Paste' to command feld
•	
User can store the log screen to text file
And there is an option whether saving will be done automatically or not. The clocktime is also marked in every line of the log.
•	User can set 'mark' into log screen by pushing defined button/key
SerialTester makes some kind of mark in the defined place of log.
•	User can select automatic scrolling on/off
•	User can select the size of log buffer
•	User can see all messages sent and received by opened communication port in log window. Self typed and/or automatically generated by SerialTester.
•	Rotating log buffer. Old ones disapear and size do not grow after limit reached
•	User can choose earlier sent commands by up/down arrows (Input buffer)

4.2 Non-Functional Requirements

•	No limit for supported motors
•	Port settings can be changed without restarting

4.3 Implementation Requirements

•	Log buffer maximum size selectable and unlimited (memory limitation)
•	Designed so RS232 protocol can be changed to ie. TCP/IP by reimplementing few classes. (uses Interface)
•	Configurable command identifiers. (What is the actual command to be sent to line)
•	Designed so that target can be changed by changing few classes (uses 'target interface')
•	No hardcoded text / target system commands. (uses resource files)
•	Window's are resizable
•	View / Model design
GUI can be changed.
•	Model uses standard C++, View is done using MFC library.
•	Uses exeption handling
•	Function/variable names and code comments are made in english. Program GUI language is english.
•	Avoid message boxes unless it is mandatory to user to acknowledge and/or make decision it to be able to continue. Information messages are shown different way.
There is probably a status line where most needed information are shown.

4.4 Constraints

•	SerialTester do not support Xray unit testing

5. Use Cases

This paragraph contains a brief description of every situation to use the program (use case). In every use case the “actor” is user.

5.1 Initialization
Frequency:	Always
Preconditions:	Target system is powered and operational. SerialTester is running.
Description:	User selects “communication setup” command [EXCEPTION: communication port is open]. User edits communication settings and exits the prosedure.

User selects “open port” command.
SerialTester opens communication port and sets its parameters [EXCEPTION: Error opening communication port].

User selects “initialization” command. [EXCEPTION: Communication port is not open] 
SerialTester sends initialization command to target system and compares the response message agaist what is expected. [EXCEPTION: target system not responding ]. Serial tester shows “initialized” message including target system response string.

User selects “close port” command. SerialTester closes and frees the communication port.
Post conditions:	Communication port has been opened and closed. Target system is initialized.
EXCEPTIONs:	1. Communication port is open: Error message is shown. Command is canceled.
2.  Error opening communication port: Error message is shown.
3. Communication port is not open: Error message is shown. Command is canceled.
4. Target system not responding: Error message including possible target system response string  is shown.

5.2 Set and send configuration
Frequency:	Frequently
Preconditions:	 Target system is powered, operational and initialized. SerialTester is running.
Description:	User selects “send configuration”. SerialTester sends last configuration to the target system [EXCEPTION: Error occurred].

User selects “edit configuration” command. 
User edits desired settings of motor and i/o parameters. User exits editing configuration.[EXCEPTION: value out of range]

User selects “send configuration” command. SerialTester sends just edited configuration to the target system. [EXCEPTION: Error occurred]

Post conditions:	New, edited configuration has been set to target system.
EXCEPTIONs:	1. Error occured: Error message is shown with responce string from target system.
2.  Value out of range: Error message is shown with name of the item and the value. Acceptable range is shown in the error message.

5.3 Retrieving status
Frequency:	Frequently
Preconditions:	Target system is powered, operational and initialized. SerialTester is running.
Description:	User selects desired motor  and then “status” command.

SerialTester sends status query to target system and receives response string [EXCEPTION: Error occurred]. SerialTester extracts response message and views conditions in human viewable way.

User selects desired motor  and then “status” command.

SerialTester sends status query to target system and receives response string [EXCEPTION: Error occurred]. SerialTester extracts response message and views conditions in human viewable way.
Post conditions:	Status of the system i/o and one motor is determined. 
EXCEPTIONs:	1. Error  occurred : Error message is shown with responce string from target system.

5.4 Running motors
Frequency:	Normal
Preconditions:	Target system is powered, operational and initialized. SerialTester is running. Motor parameters are set and sended.
Description:	User selects “run reference” command.
SerialTester sends run command to target [EXCEPTION: Motor parameters not sended]. 
SerialTester shows “running” message during the motor movements. SerialTester sends status messages to target system to determine when command has been executed [EXCEPTION: Motor run error]. When target system informs that it has reached motor reference, SerialTester shows message of reference run has been successfully executed.

User selects motor to be ran. User sets target position of the motor. 
User selects “run motor” command. 
SerialTester sends run command to target [EXCEPTION: Motors not referenced] 
SerialTester shows “running” message during the motor movements. SerialTester sends status messages to target system to determine when command has been executed [EXCEPTION: Motor run error]. When target system informs that it motor has reached its target position, SerialTester shows message run has been successfully executed. 
Post conditions:	Motors has been ran to reference position. One motor has been ran to desired position.
EXCEPTIONs:	1. Motor parameters not sended: Error message is shown. Command is canceled.
2. Motor run error: Error message including human readable reason as well as reply string from target system is shown. Command execution is canceled.
3. Motors not referenced: Error message is shown. Command is canceled.

5.5 Logging
Frequency:	Normal
Preconditions:	Two target systems are operational and communicating with each other. Spy cable is connected. SerialTester is running.
Description:	User selects “open port” command.
User sees communication between two target systems in the log window. Beginning of the line is time when corresponding message has been received. Lines are not cutted to next line even it do not fit into the window.

User presses “mark” key. SerialTester adds mark line to log window [EXCEPTION: Currently receiving line from port]. Mark line say “------MARK n” where n is running number or how many times mark key has been pressed after port opened. SerialTester do not send “MARK” text to the port. 

User selects “pause” command. SerialTester prosesses incoming lines but do not show them in the screen.
	User selects “continue” command. SerialTester continues prosessesing incoming lines to log screen.

User selects “close port” command. SerialTester closes and frees the communication port.

User selects “save log” command [EXCEPTION: Port is open].  User selects filename and path of the log file and saves the file. All information from the log window is stored to the file.

Post conditions:	Log of communication has been made with marks. Log has been saved to file.
EXCEPTIONs:	1.  Currently receiving line from port: Incoming line is received normaly and mark line is added after that. Befor next line is presessed from the port.
2. Port is open: Error message is shown, command is canceled.