Projects – Spring 2001

Click on a project to read its description.

Fujitsu Transaction Systems is one of the top three suppliers of retail systems and services worldwide. Its integration of Microsoft DNAÔ (Distributed InterNet Architecture) creates a high performance yet open platform that retailers as diverse as Best Buy and REI Sports are able to customize.

The goal of this project is to design and implement a Remote Product Build Facility. This facility will allow our developers to initiate, monitor, and manage a rebuild of our software packages from either local or remote locations. Exposure to the latest Web development technologies will be a project byproduct.

(VB, VBScript, VC++, Windows NT/2000, Microsoft FrontPage or Equivalent)

B2B Application

NBC-17 is in the business of TV Programming, Promotions, Sales, Marketing, and News. The focus is to attract larger viewing audiences and grow the station. As a result, NBC-17 will increase revenue, service our external and internal clients, and improve the overall quality of our on-air product.

In order to better serve our external clients, NBC-17 has begun to implement a business to business (B2B) solution that addresses the needs of our customers. The B2B solution has taken the form of, a web based system that increases the efficiency of interaction between sales, finance, and our customer base. This semester's project will be a continuation of a previous NC State B2B project and will expand on the overall functionality and client interaction initiated by that effort.

The current functionality of provides the ability to create online customized (per customer) presentations, allows registered customers to view market information resources and to place and confirm orders for on-air commercials. The focus of this NC State Development Team will be to expedite integration, and expand on the functionality of the existing site.

Objectives/Keys to Success:

Encryption, simplicity, accessibility, easily maintainable, user specific info, speed (download time), interactive content, data mining capabilities.

The team should research currently available Knowledge Management (KM) System packages and current concepts and theories on KM evolution. The desired future system should be able to profile and maintain "knowledge experts" by topic as well as knowledge (information stored in various systems). By using some type of connection engine based on topic search capabilities, prototype a demonstration of being able to ask (query) for knowledge and return a match of both information and "knowledge expert" that most probably would apply and contribute to the "need" implied by the query. The use of fuzzy logic, database technology, web access, etc. are all viable components to consider in putting together a demonstration capability. The demonstration may have components that are package based, developed software and simply presentation to fill in the gaps. A desired deliverable is a report on the research and explanation dialog that supports the understanding of the demonstration.

Quality Assurance Tracking Automation

Develop a strategy and prototype for automating the tracking of quality assurance test case execution. This prototype should provide a way for technicians to work their way through test cases and enter of their testing efforts. These results would be stored in a database for later analysis to determine error prone modules and to track the amount of testing that is complete.

The project team will work with our Quality Assurance manager and people on the QA team to understand current procedures for manual test case tracking. A possible implementation is to develop a prototype web-based application that allows test cases to be entered, viewed, test case results tracked, and management reports and graphics to be created. The web server for the prototype could be any platform that the team feels comfortable with using from MS-IIS on NT to Apache on Linux using Java servlets or Perl cgi programs.

This project requires that CSC students work on a multidisciplinary team with Chemical Engineering students enrolled in a corresponding senior design course.

NCSU Fermentation Manufacturing Execution System

The specific objective is to execute a preliminary engineering design of a process, automation and controls system, and paperless manufacturing execution system (MES) for the production fungal fermentation using Aspergillus niger for the production of citric acid and its purification using acid precipitation. Students will perform experiments to determine necessary technical and operating specifications, and will use the apparatus to evaluate the Manufacturing Execution System (MES) developed by the design team. Automation is required for the fermentation system. Process data collection/monitoring is also required. The process must be fully documented; all validation protocols defined and followed, all equipment validated, all analyses validated. An electronic system is required to support the following: SOPs, compounding records, batch records, batch reports, genealogy reports and equipment/maintenance logs.

The challenge for this semester will be the implementation of purification unit operations. Equipment is on order for ultrafiltration and different forms of chromatography. This project will build upon the results obtained by last year’s design team.

This project requires that CSC students work on a multidisciplinary team with Chemical Engineering students enrolled in a corresponding senior design course.

Supervisory control system for research fermentation (Glaxo/Smithkline)

Design and implementation of a supervisory control system for research fermentors operating at Glaxo/Smithkline’s RTP facility is requested.

Supervisory control software consists of on-line and off-line data acquisition and archival, as well as query and reporting tools. The main purpose of the software is to collect data on the sequence of events referred to as a "fermentation run", and to provide tools for returning data from previously archived runs.

Overview of events

The simplified order of the sequence of events in a fermentation run is as follows:

To begin a run, the user enters information on the organism and culture medium to be used in the run, then assigns a specific fermentor for the run. At this time, the software assigns a unique run identifier to this run. Using a print-out of the data entered in the first step, the operator prepares the fermentor for the run. After the fermentor is inoculated with the bacterial culture, the data acquisition begins. The vessel is harvested, and data acquisition ends. Final data on the run is entered after the cells are processed.

Data Archival

The computer hosting the supervisory control software is the bridge between the Allen-Bradley LAN and our Ethernet. CimQuest’s In-Gear ActiveX object to access the Allen-Bradley DH+ network card from Visual Basic 6.0 (support for CimQuest exists for any OLE container) has been evaluated and found to be intuitive to use and stable.

The data archival software will monitor up to 10 analog fermentation parameters from the PLC for up to 5 fermentors, and archive the data at user-defined intervals while the batch is in process. It will also allow the user to enter data for up to 5 off-line variables. The software can monitor a discrete bit in the PLC to determine when the run is in process. This bit is modulated through a button on the PanelView interface to the PLC. The data collected will be bound to the information entered for the run in the set-up phase and stored as a batch.

Data Analysis & Reporting

The final report should collate all the data available for the specified run, and should include graphs of the monitored parameters over time. Perhaps the best way to present the data generated is in the form of an Excel spreadsheet, rather than as a static document.


The project goal is to build a graphical toolkit to be used by a sales reporting application. The graphical toolkit would be a set of applets that can communicate with Java servlets to download information to be displayed. The applets should incorporate different visualization techniques such as simple graphs, geographic mapping, and geodemographic mapping.


Sales & Marketing Performance Decision Support (SMPDS) is a sales reporting tool developed and used by the Commercial & Consumer Equipment Division of John Deere. SMPDS needs a graphical toolkit to augment its reports. The users would benefit from a tool that could graphically display information reported from SMPDS. Sales information is made available for businesses to see how well their sales are doing. At a national level, sales figures are viewed to determine how sales are going by product and region. It can be used to adjust production schedules, inventory levels, sales forecast, sales incentives, and managing of sales staff. At a more granular level, territory managers use this information to determine how well the dealer organization is doing. Metropolitan Statistical Areas (MSAs) are examined to determine where the market is and how the dealers are positioned. Locally at a dealership level, sales figures are compared against previous year's sales and future goals.

When analyzing sales and marketing information one would compare this year's sales to last. Sales levels are compared by year-to-date figures. Rolling 12-month figures are compared to remove seasonal fluctuations. Comparison information is converted to a percent of change. The percent of change can quickly indicate if sales are up or down. The result of all this information is a massive set of data that get arranged in many page reports. To increase efficiency, a graphing and visualization tool can be used.


The project involves developing a set of Java applets that employ a variety of graphing techniques to enhance the visualization of sales information. The visualization tools will be used for comparison purposes, for example to quickly determine which products have sales difficulties. A desired feature would be to allow drill down capability in the reports.

Geodemographic maps of dealer and sales information are also required for this project. County maps by state, region, and North America will be produced. In these maps, counties should be colored based on up and down sales increases. An additional geodemographic for MSAs that shows county and dealer sales levels and dealer locations should be included.

A robust visualization tool should be independent of the type of information it is displaying. In this application, it should work the same whether it is displaying national or local sales figures. Geographic mapping of data needs to be more specific to the area being mapped. But, it should not be dependent of the type of information being mapped.


WolfWare is a Course/Locker Management System developed at NC State University. WolfWare is currently in phase 2 of development. Core development efforts center around the critical infrastructure pieces of the project leaving little development time for add-on tools that would enhance the overall package. The WolfWare team has identified several small add-on tools that could enhance the WolfWare environment, and can be developed without much information about the inner workings of WolfWare.

Project Description

Learning Technology Service (LTS) would like a senior design team from Computer Science to develop several ala carte tools that may be added to the WolfWare and WebCT suite of tools on campus. These tools include:

  • A Link Checker. CGI program that will traverse the links in a web site and alert user to any problems. Customized to our AFS environment, and WolfWare lockers. Follow links via AFS, checking wrap access along the way.
  • Accessibility tool: Similar to above, but will run local pages through "Bobby" and generate a report (also posts a report to LTS for archival).
  • WRAP htaccess wizard: CGI tool that will assist faculty in setting up and modifying wrap protected subdirectories in their WolfWare lockers.
  • Syllabus Wizard: CGI forms based program to assist faculty in creating and placing syllabi. Will include all the thing Faculty Handbook requires and allow faculty to add other pertinent info.
These tools can start with open source tools available on the web, but will need to be customized to fit into our environment. Perl development is required, no servlets, or server-side includes, and minimal use of javascript. WolfWare team will provide a protected environment for development work that is not part of the production system. Will also provide sample data as necessary, and/or hooks to WW perl module.

All developed tools will include documentation (for maintenance, as well as user docs), and all source code.

Redesign of University Career Center’s On-line Campus Interview Sign-Up System

Definition of Problem

NC State University’s Career Center developed the first on-line interview sign up system in the country, but it is now in great need of an update. Checking schedules, dropping resumes, and signing up for interviews can be confusing and frustrating for the user. Many activities overlap (e.g.,resume drop, checking preselect lists, sign-up) leaving users with no idea of which section they have come from and where to go next. In addition, the site does not provide direct linking to other sections, thus forcing the user to back out of the current task before beginning a new task.

Project Objective

The objective of the proposed project is the design and development of a more user friendly navigational system for on-campus interview sign-up through the Career Center, utilizing Perl as the front end tool. The site’s functionality is robust; it is the navigation of the sign-up process that needs to be more visible and understandable to the user. Users should be able to tell where they are at all times, be able to move from one activity to another with ease, should be able to check various lists and procedures of the system with ease.

During the spring semester, developers from ACS will update the student on-line resume, including both the format and the webside navigation. The senior design project team may have the opportunity to critique the design from a user’s perspective, though not necessarily be involved in the programming.

Sign-up System Description

The system used by the Center is an integrated one comprised of relational databases with updatable tables, separate database access for staff, general university access, limited employer access, and secured student access through the Career Center’s website. It was developed originally in consultation with the Career Center staff, developers in the Administrative Computing Center (ACS), student groups, and other faculty and administrators.

The web side front end, developed in Perl, connects to the Sybase database. It was designed to allow students with Unity accounts to sign up for interviews, check future interview schedules, electronically drop resumes to employers, and access employer contact information. In order to participate in this process, students must register in the Career Center by completing a registration card and must complete an on line resume and release it into the Center’s student resume database.

Last semester a Java system was created that translates recorded voice and handwriting into a web-viewable format. This system used the CrossPad2, a legal pad sized device that captures handwriting through an electromagnetic pen. The application has potential uses including distance education, online "office hours", homework solutions and exam review.

The project this semester will consist of porting the Java code to C++, using provided SDKs to directly interface with the capture device, and to provide the output in the form of Shockwave Flash rather than an applet. Students will be working under the developers of the Java system to develop a release-quality product by the end of the semester.

Students joining this project should have a working knowledge of Java, C++ and a strong knowledge of Object Oriented design concepts. Knowledge of Visual C++ is also helpful, but not required.


In days of yore in retail stores receipt printers attached to the checkout registers would print receipt information twice -- once for the customer and once for the store. The customer receipt was (and still is) torn off and given to the customer. The store's copy of the receipt would just be printed onto a roll of paper inside the printer. This roll of paper was known as the "summary journal". The summary journals were archived and could be retrieved in case of query or dispute.

Modern stores write the journal data to file. This saves the cost of the paper, and the physical space required to store the journal rolls. It also enhances the usability of the journal information by making it easy to find the roll for a specific register or day, and allows searching for all transactions carried out by a specific customer. That's the theory, at least.


Systech Retail Systems develops, supports and sells a product called "Openfield". Openfield is a modern store management system that includes two forms of electronic journal. Unfortunately, neither is completely satisfactory.

The first is an ASCII text copy of the receipt given to the customer that is kept per terminal, per day. This is difficult to search since the meaning of each piece of information in the file is difficult to determine programatically.

The second uses an XML summary of the transaction details and a browser-based reporting tool for searches. This version (written by a third party) has a quirky XML format and a clunky user interface.

We, the Openfield programming team, are about to implement an XML representation of the transaction data generated by our application. This representation will be based on a transaction schema developed by the Microsoft ActiveStoreTM initiative. However, our version of this schema is not yet defined.

The Requirements

We want you to create a new Electronic Journal (EJ) reporting tool that will use the ActiveStore transaction schema as currently defined. Later, we will update the schema and reporting tool as necessary to include Openfield specific elements. The tool should have a browser-based (IE5.5) interface and use XSL as much as possible.

Each register in the store will generate an XML record of each transaction performed at that register. You should expect that each register will, at most, perform 30 transactions an hour for 12 hours of the day. On average these transactions will contain 15 items. An average store has 8 lanes. The reporting tool must be capable of searching through a week's worth of data for a specific transaction in a reasonable amount of time. (Reasonable is defined as being quick enough that the users will not get frustrated.) How the data is organized after bring received from the registers is up to you.

The reporting tool must be capable of producing a representation of a transaction in a form similar (but not necessarily identical) to the receipt currently produced by Openfield. It should also be able to produce a summary of the transaction containing just totals and tenders information.

The tool should be able to search the EJ data based on a variety of criteria. Examples might be: Specific transaction number, specific customer number, specific tender account number (e.g. credit card number), transactions containing voids, refunds or other exceptions, transactions containing specific manager override types.

It should be possible to limit searches based on a date range, and by register number.

It should be possible to navigate to the previous and next transactions (for that register and cashier) for any transaction listed in a set of search results.

Evaluation of Linux OS and kernel features or Microsoft beta OS projects running under Dell laptops.

C-wall "buster patrol"

Format appropriate email messages to students found to be in violation of College of Engineering C-wall requirements. Track violators over multiple semesters. Web accessed database application.

Use Bluetooth wireless technology to build a prototype of a product that is of general benefit to society. See