This page contains case studies and examples of the work/projects that we have done both internally and for our customers.  Only publically available information will be shown here. 

COCAM

COCAM is a JRTwine Software application that went through the concept, architecture, design and implementation stages, and was released to the beta users in less than one man-month of time.  This also included an architectural-level change that removed the previously required RDBMS from the design, but maintained the initial relational data model used by the application.  It has just entered its second round of beta testing.
 

Delete FXP Files

Delete FXP Files is a JRTwine Software application that went through the concept, architecture, design and implementation stages, and was released to the beta users in about two man-months of time.  This included a conversion of some file-path routines to Unicode, which gave the benefit of supporting longer path-names (up to ~32Kb in length). 

The Nexus System, and the Nexus and Nexus Reporter Applications

The Nexus System is a real-time multithreaded 2-tier system that analyses and/or processes semiconductor defect information.  It used SQL Server 2000 as the back-end database.  It is a very full featured system that included features such as intrinsic detection ability (minimal training required) and email-based triggering from real-time events.

The Nexus application was the main server of the system and was also used for interactive training of libraries and specifications of output desired.  It was also the part of the system that ran in the background as a high-performance multithreaded server that processed incoming defect data in real time and placed the results into the database and/or to a XML file. 

The multi-threaded processing engine consisted of pools of Worker and Sniffer threads.  Worker threads pulled data from a FIFO queue (implemented via I/O Completion Ports) and processed the raw data and wrote results to the database or an XML file and were also responsible for real-time triggering of events.

Sniffer threads obtained files from local and remove filesystems or FTP locations, pre-processed the files to filter, validate and extract the defect information and threw that data "over the fence" to the pool of Worker threads.

The Nexus application used an internally-developed analysis engine that handled all of the defect and wafer attribute detection.

Nexus Reporter was the primary reporting application.  It reused IE and generated complex reports from the database data, including various ways to filter the obtained result sets.  A Wafer Gallery was available in the application that used GDI+ and the ListView common control and was capable of rendering, storing and showing more than 15000 wafer thumbnails at once.

James R. Twine had architectural, design and implementation responsibilities including:

•  The 2-tier system
•  The logical relational data model and the physical data model
•  The threading engine
•  The Nexus and Reporter applications
•  The installer packages for deployment of the demo and production systems

The system's design was such that as the data processing requirements changed, we were able to keep backward compatibility with previous data 100% of the time.  During real-time monitoring, the system's resource usage remains stable and has run for extended periods of time with no problems.
 

<More To Come>