MMDS – Software Application
1.0 Introduction
This Software Design Specification (SDS) describes system design for The
Magnetic Resonance Imaging Motion Detection System (MMDS) Software
1.1 Background
Motion of the subject during an MRI scan can cause the image to contain
distortions or artifacts. The MMDS application seeks to develop a way to
easily inform the MRI operator and subject in real time when non-trivial
motion has occurred. The MMDS application will do this by interfacing
with the MMDS Hardware to Software Interface.
The MMDS application will act on a synchronized schedule with the MRI in
order to provide accurate information regarding motion vs. time for the
duration of the MRI scan.
The operator will be informed of non-trivial motion through a visual alarm
shown in the MMDS application. The subject will be alerted from an
audible alarm through triggered by the MMDS application.
1.2 Statement of scope
The MMDS Software Design Specification (SDS) focuses on the functional
and technical design for the MMDS Application. This includes the
Communications, the Graphical User Interface (GUI), and the Sound
1.3 Major constraints
The MMDS Application will need to be designed to work on major
operating systems (Windows, Mac, Linux). The biggest constraint
observed by the MMDS Application will be the need to alert the users in
real time when non-trivial motion has occurred.
2.0 Data design
A description of all data structures including internal, global, and temporary data
2.1 Internal software data structure
2.1.1 RS-232 ASCII String
RS-232 ASCII Strings will be strings that are read from the Serial
Port. These Strings will be parsed into ChannelDataObjects. The
string will be in the following format:
‘s’ V1 V2 TM1 TM2 TS1 TS2 TmS1 TmS2 ch ‘x’
Where ‘s’ and ‘x’ are delimiting characters, V1 and V2 represent
hexadecimal voltage values, TM1 and TM2 represent minutes, TS1
and TS2 represent seconds and TmS1 and TmS2 represent
2.1.2 ChannelDataObject
ChannelDataObjects are used to represent information sent from
the MMDS Hardware to Software Interface over a RS-232 interface.
They will contain the following information: Voltage Level, Time,
Source Channel, and Voltage Threshold.
2.1.3 UdpFlag
A UdpFlag is simply a bit representing a boolean flag value. The
UdpFlag will represent weather or not current motion is trivial or
non-trivial. This data is sent from a 3rd party application that
determines if motion at the current time in the scan is trivial or nontrivial.
3.0 Architectural and component-level design
A description of the program architecture is presented.
3.1 Program Structure
MMDS will follow an Object oriented approach to design. We model
MMDS with a component level architectural design. This system will be
implemented using the Java programming language. MMDS will make
use of the Observer Design Pattern. This pattern is used to implement a
distributed event handling system. In our case, the Observer classes will
observe SerialCommSubject and UdpExternalMotionSubject. Whenever a
new ChannelDataObject or a UdpFlag is created, they will be sent to the
Observers via the Observer Pattern.
3.1.1 Architecture diagram
3.1.2 Alternatives
We chose to use a component level architecture design because it
would map to object oriented implementation easily.
3.2 Description for Component SerialCommSubject
SerialCommSubject is responsible for all aspects of serial communication
throughout MMDS.
3.2.1 Processing narrative (PSPEC) for component
Once prompted by the user, SerialCommSubject begins polling the
serial port for RS232 Strings. Once a string is received, it is passed
to CdoUtils so that it can be serialized into a ChannelDataObject.
These ChannelDataObjects are then passed on to all registered
SerialCommSubject will make use of the 3rd Part Library Rxtx to
simplify RS-232 Communication.
3.2.2 Component SerialCommSubject interface description.
Inputs: RS-232 Strings
Outputs: ChannelDataObjects
3.3 Description for Component MCUCommSim
This component is used strictly to test MMDS. MCUCommSim is used to
simulate the Hardware to Software Interface of MMDS. It will be run from
another computer connected over RS-232 interface.
3.3.1 Processing narrative (PSPEC) for component
Once prompted by the user, MCUCommSim will begin sending RS232 Strings across the serial port. The user can specify the
number of strings to be sent as well as the timing between each
data transmission.
3.3.2 Component MCUCommSim interface description.
Inputs: Operator Event
Outputs: RS-232 Strings
3.4 Description for Component SoundAlarm
Sound alarm is used to play sound through the PC Sound card when a
ChannelDataObject is produced that is above the threshold and a
UdpFlag is true.
3.4.1 Processing narrative (PSPEC) for component
When MMDS starts, a .wav file is loaded into memory. When the
GuiObserver receives a ChannelDataObject with a Voltage Level
that is above the threshold and the UdpFlag is true, a .wav file is
3.4.2 Component SoundAlarm interface description.
Inputs: ChannelDataObject
Outputs: Sound played through PC speaker
3.5 Description for Component CdoUtils
CdoUtils is a collection of utility methods relating to ChannelDataObjects.
3.5.1 Processing narrative (PSPEC) for component CdoUtils
CdoUtils serves two main purposes. The first is used by
SerialCommSubject to serialize RS-232 Strings into
ChannelDataObjects. The second is used by MCUCommSim to
create random ChannelDataObjects for use in testing.
3.5.2 Component CdoUtils interface description.
Inputs: RS-232 Strings
Outputs: ChannelDataObjects
3.6 Description for Component ChannelDataObject
ChannelDataObjects are used to represent information sent from
the MMDS Hardware to Software Interface over a RS-232 interface.
They contain the following information: Voltage Level, Time,
Source Channel, and Voltage Threshold.
3.6.1 Processing narrative (PSPEC) for component
ChannelDataObjects are created from RS-232 Strings by CdoUtils.
3.6.2 Component ChannelDataObject interface description.
Inputs: setVoltage, setChannel, setThreshold, setTime
Outputs: getVoltage, getChannel, getThreshold, getTIme
3.7 Description for Component GuiObserver
GuiObserver is as a conduit for ChannelDataObjects and UdpFlags
to trigger audible and visual alarms.
3.7.1 Processing narrative (PSPEC) for component
GuiObserver is used to store ChannelDataObjects into a thread
safe collection. It also stores UdpFlags in a thread safe collection.
If it finds a condition where a UdpFlag is true and a
ChannelDataObject’s Voltage Level is above the threshold, it will
cause an alarm to be thrown to the GuiManager and SoundAlarm.
3.7.2 Component GuiObserver interface description.
Inputs: ChannelDataObject, UdpFlag
Outputs: Visual Alarm, Audible Alarm
3.8 Description for Component GuiManager
GuiManager is used to create and show the Gui on the screen. It is the
main entry point for the operator.
3.8.1 Processing narrative (PSPEC) for component
GuiManager will use Java Swing components to display the Gui on
the operator’s screen. This component will contain a Text area that
will display ChannelDataObjects in real time. The operator can
invoke or terminate a scan that will start or stop
SerialCommSubject from polling the serial port. The operator can
also load a previous scan’s data.
3.8.2 Component GuiManager interface description.
Inputs: Operator mouse and keyboard events
Outputs: ChannelDataObject information in human readable
3.9 Description for Component UdpExternalMotionSubject
UdpExternalMotionSubject is responsible for opening and continuously
polling an Udp port to listen for UdpFlags.
3.9.1 Processing narrative (PSPEC) for component
UdpExternalMotionSubject will continuously monitor Udp port 8899
for a flag sent by a third party program. This flag represents
weather or not motion at the current time during a scan is trivial or
non-trivial. These flags are then sent to the GuiObserver.
3.9.2 Component UdpExternalMotionSubject interface
Inputs: Udp packet
Outputs: UdpFlag
3.10 Description for Component FileLoggerObserver
FileLoggerObserver will log all ChannelDataObjects and UdpFlags for a
given scan.
3.10.1 Processing narrative (PSPEC) for component
FileLoggerObserver will create a unique file at the beginning of
each scan. It will then store all ChanelDataObjects and UdpFlags
for that scan in the file. They will be in text format:
3.10.2 Component FileLoggerObserver interface description.
Inputs: ChannelDataObjects, UdpFlags
Outputs: File containing all ChannelDataObjects and UdpFlags for
a given scan
3.11 Software Interface Description
The software interface(s)to the outside world is(are) described.
3.11.1 External machine interfaces
This application will be connected to a Freescale HCS12
Microcontroller Unit (MCU through a RS-232 interface (DB9
Connector). This MCU is part of the MMDS Hardware to Software
Interface that converts TTL level voltages to RS-232 voltages and
marks them with a timestamp and channel data.
3.11.2 External system interfaces
This application will be exposing UDP port 8899 to listen for data
regarding non-trivial motion. This interface is exposed to listen for
data sent from another program written to determine exact times
during an MRI scan when motion will cause image artifacts.
4.0 User interface design
A description of the user interface design of the software is presented.
4.1 Description of the user interface
The user interface is built using Java’s Swing Components. MMDS uses
David Ekholm’s RiverLayout as a Layout Manager.
4.1.1 Screen images
4.1.2 Objects and actions
TextArea: Used to display ChannelDataObjects voltage, time, and
channel data.
Start Scan Button: Used to cause MMDS to start scanning serial
Stop Scan Button: Used to cause MMDS to stop scanning serial
View Log Button: Used to load a previous scan’s data.
5.0 Testing Issues
Test strategy and preliminary test case specification are presented in this
5.1 Classes of tests
5.1.1 Timing
The MMDS will be tested using the MCUCommSim Component.
MCUCommSim will send RS-232 Strings. Emphasis will be placed on
both high-speed data and varying time intervals.
5.1.2 Image Artifacts
Images generated from the MRI will undergo separate performance
evaluation. This will involve measuring the standard deviation of groups of
pixels along the borders of the images.
5.2 Expected software response
5.2.1 Timing
MMDS is expected to experience some sort of delay from the time a
ChannelDataObject is created to when it is displayed to the Operator. It is
expected that after a 5 minute scan, the delay will be no longer than 1
5.2.2 Timing
The standard deviation of the pixels on the borders of the image should be
lower than images with known motion artifacts.
5.3 Performance bounds
The audible and visual alarm should be available within 1 second after the
RS-232 String is sent to the serial port.
6.0 Appendices
Presents information that supplements the design specification.
6.1 Packaging and installation issues
Project will be packaged into a single jar using Apache Ant.