SerTi

Susanna Blomqvist
Antti Korhonen
Heikki Mylläri
Pekka Pakari

Software Plan 0.3
							4.3.2003

University of Jyväskylä
Department of Mathematical Information Technology

Authors:	Susanna Blomqvist (SBl), Antti Korhonen (AKo), Heikki Mylläri (HMy), Pekka Pakari (PPa), Ilkka Urtamo (IUt)
Title:	Software Plan for Software Project
Abstract:	The Serti project implements a software (SerialTester) for Stresstech Ltd. It will be used to test and monitor equipments controlled via RS232 line. This software plan describes structure and functionality of SerialTester. 

Version history:

Table of Contents

1. Introduction
2. Terms, Acronyms and Abbreviations
3. The Structure of the System
4. Class Structure of the Software
4.1 Classes
4.2 Command Sequence
5. User Interface
5.1 Main Window
5.2 Command Menus
6. Testing principles
7. Conclusion
8. References

 
1. Introduction

SerTi is a student software project to be carried out in the University of Jyväskylä during the spring 2003. The project implements for Stresstech Ltd a system that will be used to test and monitor equipments controlled via RS232 line.

This document defines the structure and the functionality 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ä. 

Project group will also write documents Project Plan and Requirement Specification. Project Plan describes how the project will be organized and carried out. Requirement Specification presents the requirements of SerialTester software.

Stresstech Ltd has also delivered to project group few other documents. C++ Coding Standard determines the coding standard to be used in the software. SL Communication Specs describes the commands of StressLogic, while Motor Parameters contains a list of parameters for StressLogic.

Chapter 2 explains some terms and acronyms that are used in the document. The Chapter 3 contains a brief description of the system’s structure. Chapter 4 presents class view and a brief description of classes. Chapter 5 presents graphical user interface and Chapter 6 introduces the main principles for testing. 

The coding standards implemented by the project team are defined in the C++ Coding Standard (see chapter 8: List of sources).

2. Terms, Acronyms and Abbreviations

The following terms are used in the document:

SL	(StressLogic) is a motor driver and an I/O board manufactured by StressTech Oy.	
ST	(SerialTester) is a software to test StressLogic. It will be developed by SerTi project.	
RS232	is a PC serial communication standard.	
I/O	is abbreviation for Input/Output.	
SpyCable	is special 3 headed cable used to monitor RS232 communication between two systems. Third end is connected to the PC in which program logs the messages passed between the monitored systems.	
GUI	is the abbreviation for graphical user interface.	
View/Model	is designing concept where model (core where functionality is) is separated from View (GUI). This means there is no real functionality in GUI classes.	
STL	(Standard Template Library) is a C++ library that provides a set of easily composable C++ container classes and generic algorithms (template functions).	
MFC	(Microsoft Foundation Class) is Microsoft’s class library for Windows based softwares.	

3. Class Structure of the Software

SerialTester will be used to test and monitor equipment controlled via RS232 line (serial port). The software will especially be developed for StressLogic, which is a logical motor driver and I/O board manufactured by Stresstech Ltd (see Requirement Specification for details [3, page 3]). At this moment all testing is made by hand using HyperTerminal, while SerialTester should make the configuring and testing of the system considerably easier.

In this chapter the structure of the SerialTester software will be presented.

3.1 Classes

Figure 1 shows the associations between the various classes of the software. The class methods listed are preliminary examples to demonstrate the function of that class, and they are not intended to be representative of the classes’ method base when finished.

Figure 1: SerialTester class structure diagram.

A description of each of the classes follows. The following six classes will be implemented in standard C++.

IControl is the abstract base class that holds the generic (non-SL) commands necessary for operating the motors. These methods form a standard, generic interface for motor usage. Only if the command base of the underlying system is expanded significantly will this interface class be affected. Revisions in command structure and/or execution can be implemented by changing only CSlControl and/or CSlPara.

CSlControl inherits IControl. It defines the implementation for each of the generic command methods. In these implementations the helper class CSlPara is used, effectively converting IControl’s generic commands into SL command strings. These strings are transferred to the communication class (initially CSerialComm, can be changed with ease as required) via the interface defined by IComm.

CSlPara manages the command base that is used to translate the generic commands into their SL equivalents. It also stores, writes and reads all SL specific parameters.

IComm is the abstract base class that holds the generic communication protocol commands, much like IControl holds the generic system control commands.

CSerialComm inherits IComm. It defines the implementation for each of the generic communication commands, handling all internal procedures of serial traffic invisibly. CSerialComm also stores all RS parameters.

CTermLog contains the implementation for the save/load functions of the terminal and the internal logic of the command scripting functionality of ST. It handles all logging requests.

The following classes are user interface specific and will be implemented in MFC. Changes made to them do not affect the actual functionality of the software.

CLogView and CTerminalView handle the controls and visual input/output of the log and the terminal window, respectively. CStatusLeds takes care of the motor status LED rows in a similar fashion. CMainView is the catch-all class that handles the rest of the controls, most importantly the motor controls.

CSlParaDlg is responsible of the SL parameter dialog. It communicates with CSlPara directly. CSerialParaDlg is the class that handles the RS-232 parameter dialog. It communicates with CSerialComm directly.

3.2 Command Sequence

Figures 2 and 3 show the basic command sequence and the standard response sequence of the software. Every command and response is handled in the same fashion, thus multiple sequence diagrams would be redundant.

Figure 2: Basic command sequence diagram.

The command sequence in figure 2 is initiated by the user via a user interface class (which class specifically is irrelevant, as all cases are handled similarly). This triggers a call for the relevant generic command method of CSlControl, which uses CSlPara to translate the command into SL syntax and calls for the generic ‘send’ method of the communication class, CSerialComm. In addition to this, CSlControl simultaneously sends a request to log the command to CTermLog. CSerialComm then handles the actual transition.

The response routine is similar, albeit in reverse (see fig. 3). Once traffic is detected by the communication class, a WinAPI call triggers the CSlControl routine for requesting a response from the communication class. The response string is returned, and CSlControl again sends a logging request to CTermLog. The response string is forwarded to the appropriate UI class, which visualizes it in whichever way it is configured to.

Figure 3: Response sequence diagram.

4. User Interface

In this chapter the SerialTester GUI is explained in detail. 

4.1 Main Window

Figure 4 describes the main window. It is divided in three logical parts: the motor controls, the log/terminal view and the controller part.

Figure 4: Main window.

The main window contains three motor control boxes. They all have the same controls and status displays. They include driving controls, Start and Stop buttons, a reference position button and a target field where you can enter the position where the motor will go when you press the Start button. The status bits of the motor are shown with red LEDs. When you press the Read button, SerialTester will update the status and position of the motor in question. With the Param button you can open the parameters dialog (shown in Figure 5). Note that the physical motor is specified with a number right after the control label (for those situations where you have more than three motors).

Figure 5: Parameter setup dialog.

From the dialog you can send all parameters to the motor (OK button), as well as save and load the current parameter status.

In the rightmost part of the main window (see Figure 4) you can see the terminal and log areas. In the log view, you can see your commands and StressLogic’s responses to them. The log view is scrollable and you can insert a mark row by pressing the Mark button (or Ctrl-M). You can also save the log to a text file. By pressing the Pause button, the log can be inspected without hinderance from incoming lines. When you continue the log (same button), all the messages that StressLogic has sent while your log was paused will appear in the end of the log area.

In the terminal field, you can enter StressLogic commands manually by typing them in the field and pressing the Send button or Enter on the keyboard. In addition, you can scroll the text area to see the command history and load or save command queues from or to a specified file. When you load a command queue file (a text file with one StressLogic command per row) it is inserted in the terminal view. After this, you can press Run all to send all commands to StressLogic or select the line with the command you want to send and press enter. You can also use the Save button to save the entire command history to a text file. Note that you can also use the Microsoft Windows copy or paste function in both areas.

You can change the size of both the log and terminal views horizontally by resizing the main window.

In the bottom of the main window are the StressLogic status display and the status bar. The SL status display shows the controller’s general status with red LEDs and its I/O status with yellow LEDs. As in the motor control boxes you can update the information by pressing Read.

Note that when you have checked the autostatus option from the command menus, the status information for all the motors and the controller are updated automatically. In other words, you don’t have to click any Read buttons. You can set the polling interval (the amount of time after which the status is updated) from here too (in milliseconds). The default is 100.

4.2 Command Menus

The command menus are located in the upper part of the screen. 

In File menu you can open and save the log view and terminal command queue files. You can also exit the program. The commands in here are: “Open Log”, “Save Log as”, “Open Command Queue File”, “Save Command Queue File as” and “Exit”.

In Setup menu you can set logging and motor parameters as well as the control and autostatus options. In Controls submenu, you can assign a physical motor for each of the three controls. The commands in here are: ”Log Buffer Size”, “Parameters” (Opens a submenu with the selections “Motor A”, “Motor B” and “Motor C”), “Autostatus”, “Autostatus Interval” and “Controls” (Opens a submenu with the selections “Motor A”, “Motor B” and “Motor C”, which all open a submenu where you can select the physical motor).

In Connect menu you can open and close the communications (RS232) port, edit its settings and connect to StressLogic. The commands in here are: “Connect”, “Open Port”, “Close Port” and “Port Settings”.

In Help menu you can view the help files and general information about the program. The commands here are: “Help” and “About”.

5. Testing principles

The testing principles implemented in the project will be defined in a later revision of this document.

6. Conclusion

Serti group implements software that is meant to test and monitor StressLogic and other equipments. This document describes how the system will be implemented and how does the user interface look like. Overall, this plan describes how the software and its components are implemented. 

7. References

[1] Hoff Tedd, “C++ Coding Standard, an edited version”, Stresstech Oy, 2002.

[2] Pietilä Ilkka, ”SL comm. Specs”, Stresstech Oy, 2002.

[3] Susanna Blomqvist, Antti Korhonen, Heikki Mylläri, Pekka Pakari, “Requirement Specification”, University of Jyväskylä, Department of Mathematical Information Technology, 2003.