Communication Requirements
From IGSTK
Contents |
Purpose of Communication Class
A Communication object provides the link between a Tracker object and the physical tracking device itself. The reason that the Communication object is distinct from the Tracker object is to allow for different forms of communication, for example, to allow communication with a remote device via the ethernet, or to allow communication to be saved to a file and replayed for testing purposes.
Use of the Communication Class
The communication class will be used by:
- 1. the application, which will be responsible for instantiating the Communication and setting all necessary communication parameters
- 2. the Tracker class, which will open communication with the tracking device, send and receive information, possibly change some communication parameters, and close communication
The Tracker class will be responsible for opening communication except under exceptional circumstances, such as testing.
Requirements of the Communication Class
The Communication class will:
- 1. be derived from itkObject
- 2. be able to communicate ascii data and binary data
- 3. have a method that attempts to write out a block of ascii or binary data of a specified size to the device
- 3.1. automatically flush all output when the "write" method is called
- 3.2. report an error if the data could not be sent
- 4. have a method that attempts to read a block of ascii or binary data of a specified size from the device
- 4.1. automatically terminate the read if a specified special character is read (for the Aurora, the special character that marks the end of a reply is the carriage return)
- 4.2. report a timeout if the reply is not received within a specified period of time
- 4.3. report an error if there is some other reason that the read of the data failed
- 5. have a method for opening communication
- 5.1. not have a method for setting communication parameters, though specializations (subclasses) of the Communication class should have such methods
- 6. not have a state machine, though its subclasses should have state machines
Requirements For Consideration
- define a protocol for embedding communication-device specific control information inside a serial stream of data.
The above requirement will solve a difficult issue with our existing Communication class: the AuroraTracker must communicate via its Communication object without doing any run-time checking to see if its Communication object is a SerialCommunication object or some other kind. Hence, the AuroraTracker is unable to send a "serial break" to the Aurora device or to adjust the baud rate of the serial port.
If embedding of control information is allowed, then the AuroraTracker can simply use the Communication::Write() method and embed the appropriate serial control info in the string that is sent. If the Communication object is a SerialCommunication object, it will interpret the control information and take the specified action. If the Communication object is a file, the control information will be saved in the file. If the Communication object sends text over the ethernet, then the embedded control info will also be sent over the ethernet and can be decoded on the other side.
The telnet protocol defines an extensible method for embedding control information that could be adopted by IGSTK.
The following related requirement could also be used:
- the Communication class will have generic methods to set and get communication control parameters
For this requirement, the Communication define the following method:
- void SendControlParameter(ControlParameterToken param, ControlParameterValue value)
Then in order for the AuroraTracker to change the serial port's baud rate, it would do this:
- m_Communication->SendControlParameter(Communication::BaudRate, Communication::BaudRate9600)
If *m_Communication is a SerialCommunication object, then it will take the specified action. If it is some other kind of Communication object, we could either set the requirements so that it 1) ignores the information or 2) embeds the information in the communication stream.
Rejected Requirements
The rejected requirement below is just made up as an example, but for each "requirements" page there should be a "rejected requirements" section to avoid continually retreading old ground. When a requirement gets rejected, it should be noted along with the reason that it was rejected.
- thread-safety: add Lock() and Unlock() methods so that a particular thread can temporarily gain exclusive control over the Communication object (rejected because only the Tracker object should be using the Communication object after communication has begun, so locking is unecessary)
