SerTi

Susanna Blomqvist
Antti Korhonen
Heikki Mylläri
Pekka Pakari

Software Plan 1.0
							24.4.2003

University of Jyväskylä
Department of Mathematical Information Technology

Authors:	Susanna Blomqvist (SBl), Antti Korhonen (AKo), Heikki Mylläri (HMy), Pekka Pakari (PPa)
Title:	Software Plan for the SerTi Project
Abstract:	The SerTi project designs and develops the SerialTester software for Stresstech Ltd. This software plan defines the structure and functionality of SerialTester.

Version history:

Table of Contents

1. Introduction
2. Terms, Acronyms and Abbreviations
3. Class Structure of the Software
3.1 Classes
3.2 Command Sequence
4. User Interface
4.1 Main Window
4.2 Command Menus
4.3 Parameter Dialog
5. Testing Principles
6. Conclusion
References

 
1. Introduction

SerTi is a student software project that shall be carried out in the University of Jyväskylä during spring 2003, under the authority of the Department of Mathematical Information Technology. The project will design and develop SerialTester, a Windows-based application suitable for testing and/or monitoring equipment controlled via RS-232 bus, as per requests of the client, Stresstech Ltd.

This document defines the structure and functionality of SerialTester. It serves as a development guideline for the project team. The project team will also produce the documents Projektisuunnitelma (Project Plan) and Requirement Specification. Projektisuunnitelma describes how the project will be organized and carried out, while Requirement Specification presents the functional requirements of SerialTester software.

Stresstech Ltd has also delivered to the project team a few other documents: C++ Coding Standard determines the coding standard to be used in the software, SL Communication Specs describes the syntactic instruction language used to command and configure StressLogic, and finally Motor Parameters is a short list of parameters for StressLogic.

Chapter 2 provides the definitions for the critical terms and acronyms used in the document. Chapter 3 presents the class structure of the software, complete with descriptions of the classes. Chapter 4 demonstrates the SerialTester graphical user interface. Chapter 5 describes the primary testing principles of the software.

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 the testing/monitoring software for StressLogic that will be developed by the SerTi project.	
RS-232	is a PC serial communication standard.	
I/O	is the abbreviation for Input/Output.	
SpyCable	is a special 3 headed cable used to monitor RS232 communication between two systems. Third end is connected to the PC that logs the traffic between the monitored systems.	
GUI	is the abbreviation for graphical user interface.	
View/Model	is a design paradigm where model (the core of the software) is separated from view (GUI). In other words, no part of the actual software functionality resides within the 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 software.	

3. Class Structure of the Software

In this chapter SerialTester’s class structure will be presented.

3.1 Classes

Figure 1 shows the associations between the various classes of the software, as well as a major portion of the classes’ method base. Class attributes and the MFC-based methods of the various dialogs are omitted for the sake of clarity.

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, and is arguably the single most important class, effectively the central point of the software. It defines the implementation for each of the generic command methods. In these implementations the helper class CSlPara is used to basically convert 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.

In addition to all this, CSlControl holds a simple queue-type structure for matching SL responses to commands that prompted them.

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. This architecture enables relatively trouble-free shifting from serial communication to, for example, TCP/IP.

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 and pause/continue 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.

CMainDlg is the central GUI class and represents the entire main dialog. It communicates directly with CTermLog and via IControl, CSlControl. It handles all the controls, the status indicators, the message bar and the visual input/output of the log and terminal windows.

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

3.2 Command Sequence

Figures 2 and 3 on the next page 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.

The command sequence in figure 2 is initiated by the user via one of the dialogs (which one 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 figure 3). The communication class waits for serial traffic in another thread, invisibly. Once traffic is detected, it sends a message to CMainDlg, which is then processed using standard Windows message handling. This triggers a call for 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.

 

To the left: Figure 2 - Basic command sequence diagram.
To the right: Figure 3 – Response sequence diagram.

4. User Interface

In this chapter the SerialTester GUI is described in detail.

4.1 Main Window

Figure 4 shows the main window. It’s divided into three logical wholes: the motor controls (upper left), the log/terminal view (upper right) and the controller status view (below).

Figure 4: Main window.

4.1.1 Motor Controls

The motor controls are split in three sets of identical controls and status displays, one for each motor. These common controls consist of  two arrow buttons for manually driving the motor, Start and Stop buttons, a calibration button and a target field where the user can enter a position value: once the Start button is clicked (or the appropriate shortcut, yet undefined, pressed) the motor will start to run towards that position value.

The status bits of the motor are shown as red LEDs. When the user clicks the Read button, SerialTester updates the status and position of the motor in question. Clicking the Param button opens the parameter dialog (figure 5). 

4.1.2 Terminal/Log

The terminal/log view is divided in two parts. Upper part is the log, where the user’s commands as well as SL responses are displayed, complete with relevant date/time information.

The controls for the log view are located immediately below it. The user can insert a marker row into the log by clicking the Mark button (or pressing Ctrl-M). Save button saves the log into an ASCII text file. When the Pause button is clicked, the log updates are frozen, so that it may be inspected without hindrance from incoming data. Once this is done, the button’s label changes to Continue, and a single click on it will both resume the logging as normal and update the log with all messages sent and received while the log was paused.

The lower part of the view is reserved for the terminal, a multi-line input field  where the user can manually type commands and send them to SL by either clicking on Send or pressing Enter on the keyboard. In addition to this, the user can both save and load command script files (via the Save/Load buttons, obviously), then execute them with the Run all button. Clicking on this will automatically send every command in the entire command history to SL in a sequence.

Both parts are scrollable, and resizing the main window horizontally allows the user to expand both views. Standard Windows copy/paste works in the terminal view. The log is read-only, thus the user can only paste to it.

4.1.3 Controller Status

The bottom part of the main window is reserved for the controller status block. It consists of (left to right) a large Read button, the clicking of which will update everything in the status block, the controller’s I/O byte status shown as yellow LEDs, a green power indicator led and below it, two red warning LEDs.

The output LEDs are clickable: a click on a LED sends a command to turn that LED on/off.

Below all these is the status bar where internal status changes of Serialtester are displayed.

4.2 Command Menus

The command menus are, as per Windows standard, located in the upper part of the screen. 

Via the File menu the user can save the log and open/save the command queue files, mirroring the save/load buttons in the terminal/log view, and naturally exit the program. The commands are: Save Log as, Open Command Queue, Save Command Queue as and Exit.

Via the Setup menu the user can set the parameters for individual motors, mirroring the Param button in the motor controls. The user will also be able to set autostatus (defined later) on/off and access the Preferences dialog, wherein the maximum log buffer size and the autostatus polling interval are set. The commands are Preferences (initiates the Preferences dialog (detailed description omitted from this document)), Parameters (opens a submenu with the selections Motor A, Motor B and Motor C, each corresponding to the parameter dialog of one motor) and Autostatus (checkmarked on/off).

Autostatus: SerialTester is able to update the status of the motors, I/O bits and the system itself automatically on a set interval (default 100 ms), negating the need for manual updates – in other words, sparing the user from the trouble of clicking on one of the Read buttons each time a status check is required. This option is by default on.

The Connection menu holds the options for opening and closing communications and sending the initialisation command to SL. The comm. parameter dialog (omitted from this document) can also be accessed here. The commands are Connect, Disconnect, Connection Settings and Initialize SL.

Finally, the Help menu allows the user to view the on-line help and general information about the program. The commands are Help and About.

4.3 Parameter Dialog

Figure 5 shows the motor parameter dialog. From this dialog all motor parameters can be set, saved in a setting file, loaded from one and sent to SL. The controls in this dialog should be self-explanatory and will not be discussed further.

Figure 5: Motor parameter dialog.

5. Testing Principles

Individual components of SerialTester are subjected to informal preliminary testing by their coders in order to eliminate any glaring errors or omissions as soon as possible. Formal integration and software testing will be done by the project group near the completion of the project. In addition to this, Stresstech Ltd will test the usability of the software in real-life use situations. See the SerTi Testing Plan for details.

6. Conclusion

SerTi project implements software for testing and monitoring StressLogic and other equipment. This document described how the software and its components will be implemented.

References

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

[2]	Pietilä Ilkka  and Urtamo Ilkka, ”SL Comm. Specs”, Stresstech Oy, 2002.

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