Projects – Spring 2005

Usability Test Logging Application

In our usability lab, the test administrator takes notes and categorizes user and system activity during the test. Currently, the logging application is slightly more functional than Microsoft Notepad. Using the current tool, it is very difficult to summarize data across users, products, test sessions, etc. We need a full-feature logging application that facilitates data entry, data extraction, and simple analyses. As part of logging user activity, the tool should connect to a Sony DSR-20 digital tape deck to capture the DV-CAM timecode. This time code needs to be linked to each log activity that is recorded. After the test, the user should be able to query the log and create an edit decision list, based on time codes, that can be imported into Adobe Premiere. Figuring out how to link it to SAS, to support more complex analysis (e.g., text mining), would also be helpful. The project will involve developing a data model, instantiating that in some form, and developing the data entry, query, and anlysis GUIs.

The application should be a rich-client using Java and MySQL.

Health Physics Exposure Reporting Application

The Health Physics Exposure Reporting application will manage radiation exposure data as required by nuclear industry standards. Members of the nuclear industry are required to manage personnel radiation exposure at the lowest levels possible. ALARA reviews provide a vehicle for accomplishing this. (ALARA = As Low As Reasonably Achievable) -- this term is used throughout the nuclear industry. This application will collect and catalogue exposure estimates, personnel contamination exposures, and a variety of other related data for reporting purposes.

A companion System Administrator tool will provide data entry and management of data updates and/or deletions. The Administrator tool must bypass most Passport program logic to allow performing functions not supported through Passport program logic. Examples include changing worker IDs on exposure records, altering ALARA task statuses, marking and unmarking RCA entries as covered by TLD, updating TLD facilities, etc.

Both applications need to support the following:

• Use of Passport security profiles for application access based on user ID and Passport facility.
• Auditing of record inserts, updates, and deletes.

Technology to be used for these applications is .NET web pages.

Glossary:

RCA - Radiation Control Area - This is a restricted access area in the plant that requires enhanced controls for radiation exposure.

TLD - thermal luminescent dosimeters - primary personnel dose monitoring device.

Dealer Jobs Website Phase II

Last semester the Senior Design Team for John Deere started a project to provide job seekers access to job postings for John Deere Dealerships. That successful project was publicly release on January 1st. John Deere would like to continue with the development of this application in the Spring Semester. There are a few critical enhancements that are needed to increase the functionality of the system. The enhancements include: Searching by Distance from Job Seeker, user tracking and Dealer reporting, and a Billing solution for Dealer postings. This project will involve the full life cycle of these enhancements. It will include requirements gathering, design, implementation, and deployment. The deployment of the enhancements to production should occur prior to the final presentation.

Dealerjobs.Deere.com is implemented using Java J2EE technology and a relational database. You will use: Java, Java Servlets, JSPs, JavaScript, relational database, and SQL. The senior design team will have access to (i.e., be able to consult with) the local John Deere web application development team, WebWorks.

Cross Platform Performance and System Status API

Project Description

The project involves designing and implementing a consistent library for reporting system status. Most operating systems maintain a plethora of status and performance counters which are exposed through various interfaces. These interfaces include user space tools such as vmstat and iostat, the /proc filesystem, POSIX calls such as getrusage, and platform specific APIs. While many counters are independent of the underlying platform, application writers must often create platform specific hooks for them. The goal of this project is to develop a library to access such counters in a consistent manner.

The API will:

• Report basic system information (# CPUs, memory, mounted devices, etc)
• Report system status counters (CPU busy, context switches, interrupts, etc)
• Report IO counters (# disk ops, latencies)
• Be portable across at least Linux, Solaris, AIX, HP-UX, FreeBSD, and Windows
• Be simple to use and statically link to applications such as our sio load generator

In addition to defining the API, the team will be expected to implement it on at least Linux and possibly Windows. The implementation will use native hooks (probably /proc in Linux, Perfmon APIs in Windows).

Obstacle Detection & Avoidance Using LADAR

Project Description

Congress has issued a mandate that 33% of all US military vehicles must be autonomous by the year 2015. DARPA, Defense Advanced Research Projects Agency, is the central research and development organization for the U.S. Department of Defense and is the organization responsible to develop autonomous vehicle technologies for the military. DARPA has been working with large defense contractors to accomplish autonomous vehicle operation but has been very unhappy with the results. In order to stimulate development, DARPA created a race that was open to anyone interested in developing autonomous vehicle technologies. The 2005 DARPA Grand Challenge is a race that requires fully autonomous vehicles to follow a predefined course across the desert. It is billed by DARPA as Los Angeles to Las Vegas. The actual course is made available 2 hours before the start of the race. It is a series of GPS waypoints that describe the course, which may be up to 150 miles in length. Each segment of the course (a segment is the distance between two consecutive waypoints) has a maximum speed and a width associated with it. This forms an area that the vehicle is allowed to operate in. In order to win the $2 million prize, the course must be completed in 10 hours.

To participate in the 2004 race, teams were required to write a proposal that described how the team was going to approach the problem and how they would address several safety issues. Insight Racing's proposal was 1 of 19 that were accepted by DARPA as "completely acceptable", meaning it met all the requirements of DARPA. A total of 25 teams were invited to the "QID" (Qualification, Inspection, and Demonstration) leading up to the March 13, 2004 race. The QID was at the California Speedway where DARPA set up a 1.5 mile closed course with artificial obstacles. Teams needed to pass an inspection that their vehicle did what the accepted proposal said it did, and then needed to complete the 1.5 mile course to show their capabilities for participating in the race. Only 20 teams made it to the QID and 5 were able to pass the closed course test. A total of 15 teams were allowed to participate in the race. Of these 15 only 6 teams made it past the 1 mile point in the course and the best team made it 7.4 miles.

Insight Racing did not make it to the 2004 QID due to lack of sufficient funding, but we have developed a prototype vehicle that uses GPS, video cameras, and ladar unit for navigation and obstacle detection. DARPA will conduct another race in October 2005. Insight Racing is continuing their work to prepare for the 2005 Grand Challenge race and is excited to work with NCSU and Cisco to develop these new technologies. We feel our work together will place us in a very competitive position for the next race.

Specifically we are looking to advance the following technology to navigate and avoid obstacles:

We want to develop software to assist with obstacle avoidance. This will require the ability to process real time information describing the area in front of the vehicle and to provide commands to the vehicle to guide it around objects such as rocks and holes, and to detect discontinuity in the ground that the vehicle cannot maneuver around. This processing must be done in real time to support vehicle speeds of up to 50 mph. Processing the data in real time is very challenging and new algorithms need to be developed to detect and process data that is critical to the operation of the vehicle.

The sensor unit to be used is a "LADAR" device, manufactured by SICK. This unit is a laser range finder that continuously sweeps 180 degrees in front of the vehicle. Distance data is returned for each degree of the sweep and provides the distance in centimeters to objects in its range (about 40 meters). For this project, we wish to mount the SICK ladar over the windshield, pointing down to a point in front of the vehicle. This will allow us to "see" the ground and objects approaching the vehicle. If we are on a roadway, we should be able to "see" the edges of the road and use that to provide appropriate steering information to the system controller. Programming language is C on Red Hat Linux. Program development will consist primarily of analyzing the SICK ladar data array in real time to determine objects and boundaries.

Scene Analysis

Project Description

Congress has issued a mandate that 33% of all US military vehicles must be autonomous by the year 2015. DARPA, Defense Advanced Research Projects Agency, is the central research and development organization for the U.S. Department of Defense and is the organization responsible to develop autonomous vehicle technologies for the military. DARPA has been working with large defense contractors to accomplish autonomous vehicle operation but has been very unhappy with the results. In order to stimulate development, DARPA created a race that was open to anyone interested in developing autonomous vehicle technologies. The 2005 DARPA Grand Challenge is a race that requires fully autonomous vehicles to follow a predefined course across the desert. It is billed by DARPA as Los Angeles to Las Vegas. The actual course is made available 2 hours before the start of the race. It is a series of GPS waypoints that describe the course, which may be up to 150 miles in length. Each segment of the course (a segment is the distance between two consecutive waypoints) has a maximum speed and a width associated with it. This forms an area that the vehicle is allowed to operate in. In order to win the $2 million prize, the course must be completed in 10 hours.

To participate in the 2004 race, teams were required to write a proposal that described how the team was going to approach the problem and how they would address several safety issues. Insight Racing's proposal was 1 of 19 that were accepted by DARPA as "completely acceptable," meaning it met all the requirements of DARPA. A total of 25 teams were invited to the "QID" (Qualification, Inspection, and Demonstration) leading up to the March 13, 2004 race. The QID was at the California Speedway where DARPA set up a 1.5 mile closed course with artificial obstacles. Teams needed to pass an inspection that their vehicle did what the accepted proposal said it did, and then needed to complete the 1.5 mile course to show their capabilities for participating in the race. Only 20 teams made it to the QID and 5 were able to pass the closed course test. A total of 15 teams were allowed to participate in the race. If these 15, only 6 teams made it past the 1 mile point in the course and the best team made it 7.4 miles.

Insight Racing did not make it to the 2004 QID due to lack of sufficient funding, but we have developed a prototype vehicle that uses GPS, video cameras, and ladar unit for navigation and obstacle detection. DARPA will conduct another race in October 2005. Insight Racing is continuing their work to prepare for the 2005 Grand Challenge race and is excited to work with NCSU and Northrop Grumman to develop these new technologies. We feel our work together will place us in a very competitive position for the next race.

Specifically we are looking to advance the following technology to navigate and avoid obstacles:

One of the key requirements of an autonomous vehicle system to be able to compete in the DARPA Grand Challenge is to have a real-time capability to process video images captured by cameras on the vehicle. These images must be processed to provide a means of detecting and avoiding obstacles in the immediate area of the vehicle. The navigational element of the Grand Challenge starts with a sequence of DARPA supplied waypoints (latitude, longitude) that gives the general path to follow. This path must be refined by additional on-board systems. One of these is a video processing subsystem. To be competitive, a vehicle must complete the course in 10 hours (i.e., average 21 MPH over the entire course). This average speed requirement places a constraint on video processing time.

Previous senior design projects have developed scene analysis software to recognize obstacles and recommend a clear path. The first goal of the proposed project is to improve the computational speed of these calculations in order to meet real-time requirements for vehicle speed. This can be accomplished by re-coding scene analysis software to utilize vector processing instructions available on workstation processors.

A second focus of this project is to develop an ability to process video images from two cameras to produce a stereo image of the terrain in view. A stereo video image inherently contains depth information that is crucial to obstacle avoidance.

Programming language is C on Red Hat Linux.

Desktop Archival System

Develop a client centric system that manages PC files on the local hard drive that require either backup/restore capabilities and/or archival and retention management capabilities on a designated server. The system should fully manage file moves with appropriate additions and deletions. The system should provide an index and basic search capabilities for all files submitted to the system for management. Backup and retention rules will be imported and managed as an administrative component of the system. A challenge will be to determine and document to what extent OLE may be supported by the system. Additional challenges may include consideration for macros for launching applications and how best to integrated the system into the desktop environment.

Management Performance Estimator

Project Description

Celerra Manager is a Web-based management tool for EMC's Celerra File Server, a NAS (Network Attached Storage) product. It uses the latest web development technologies to provide an intuitive, easy-to-use interface for ubiquitous access to Celerra's management function. Celerra Manager presents the user with pages where the user can view the properties and perform actions on the underlying "objects". This project would develop a web-based performance estimator tool that will be used by the Celerra Manager team for finding performance problems and creating new pages. For example, we may want to develop a web page in our management utility that uses 3 file system properties (file system name, file system size, and file system quota) and a network interface property (IP address). The estimator tool would then estimate the elapsed time it would take to display this page.

Resources needed

• Desktop workstation
• JRE
• JDK

Recommended skill set

• Basic web development
• Java
• JSP
• Scripting
• Flat text database processing

Data Sets Provided

• Raw timing data for several objects. The data contains timing for individual properties in separate requests as well as all properties in the same request.
• XML request/response dump where objects and properties for existing pages can be extracted.

Deliverables

• Requirements definition document which includes results from:
• Algorithms for finding objects and properties in the 2 data sets and dealing with new objects and data sets.
• Algorithm for determining performance derived from several objects.
• Investigation to determine the best way to get input and present results in a web-based tool.
• An architectural design definition.
• Functional specification(s) for construction of the actual software.
• Weekly written status reports on progress.
• Web-based tool to report estimated performance of current pages.
• Extension to tool allowing user to select a set of properties for performance estimation.
• Source code and scripts for the actual tool(s), any tool or test software sources, and documentation (user's guide) for the implementation.
• Test specification defining use cases and test assertions, test tools, and a test report demonstrating how the software performed relative to each test case and assertion.
• Overview presentation and written report outlining the requirements, the methodology, software components, implementation, results, and lessons learned based on the work done

Company Background

EMC Corporation is the world leader in products, services, and solutions for information storage and management.

We help customers of all sizes manage their growing information-from the time of its creation to its archival and eventual disposal-through information lifecycle management. EMC information infrastructure solutions are the foundation of this mission. An EMC information infrastructure unifies networked storage technologies, storage platforms, software, and services to help organizations better and more cost-effectively manage, protect, and share information.

EMC Automated Networked Storage combines SAN (Storage Area Network), NAS (Network Attached Storage), and CAS (Content Addressed Storage) environments into an integrated networked storage infrastructure. Combined with our open storage software products we unify networked storage technologies, storage platforms, software, and services to enable organizations to better and more cost-effectively manage, protect and share information.

Our vision is to create the ultimate information lifecycle management company-to help our customers get the maximum value from their information at the lowest total cost, at every point in the information lifecycle.

The Research Triangle Park Software Design Center is an EMC software design center. We develop world-class software that is used in our NAS, SAN, and storage management products.

Value to EMC

Internally, we need a tool to estimate performance of any page (current or new) when adding properties or features to Celerra Manager. The tool will also be used to estimate the performance of current pages given new data timing sets. This will help us to save time and money in that we will no longer need to develop and time a prototype web page for performance vs. working from paper designs. This will improve the speed of our development process.

Clearcase Source Code Evaluation Tool

Project Description

This project will develop a software-program to quantify changes in EMC's software repository. The information generated allows EMC Managers and Architects to determine a historical pattern of software development versus software defects, and in turn enables them to realistically forecast defects and repair overhead in future releases.

Currently, source code is stored in a Rational Clearcase database (VOB). This database contains all the relevant information to do a qualitative analysis of changes in the source code base.

The project consists of developing a User Interface to an Analysis Engine. The Analysis Engine will then present results that can be displayed graphically, or written to files for future analysis using industry-standard tools.

It is expected that a user can specify a time period, identify an area of software, and the program will produce a list of files that were modified during that time period plus produce information such as number of lines of code added, deleted and modified for each file.

It is not possible to provide a local instance of the Clearcase VOB. Thus, this team will leverage the concept of remote engineering working in detail with EMC engineering. Much of the design work will be done to specifications, testing will be performed by EMC on behalf of this team, and regular interaction (via e-mail & phone) with EMC engineering will be provided.

Resources needed

• Desktop workstation

Recommended skill set

• Microsoft Windows graphical application development
• Knowledge of C/C++
• Knowledge of ClearCase, RCS, or CVS could be helpful, but is not required
• Scripting

Resources Provided

• Source code of previously created java prototype without graphical interface
• Draft engineering requirements specification

Deliverables

• Requirements definition document.
• Design specification(s) for construction of the actual software. This specification must outline the graphical interface layout, construction methodologies for each module, and interface specifications for the necessary interactions with the ClearCase server.
• Weekly written status reports on progress.
• Source code and scripts for the actual tool(s), any tool or test software soures, and documentation (user's guide) for the implementation.
• User's guide for the tool for teach the engineers who will use this tool.
• Test specification defining use cases and test assertions, test tools, and a test report demonstrating how the software performed relative to each test case and assertion.
• Overview presentation and written report outlining the requirements, the methodology, software components, implementation, results, and lessons learned based on the work done.

Company Background

EMC Corporation is the world leader in products, services, and solutions for information storage and management.

We help customers of all sizes manage their growing information-from the time of its creation to its archival and eventual disposal-through information lifecycle management. EMC information infrastructure solutions are the foundation of this mission. An EMC information infrastructure unifies networked storage technologies, storage platforms, software, and services to help organizations better and more cost-effectively manage, protect, and share information.

EMC Automated Networked Storage combines SAN (Storage Area Network), NAS (Network Attached Storage), and CAS (Content Addressed Storage) environments into an integrated networked storage infrastructure. Combined with our open storage software products we unify networked storage technologies, storage platforms, software, and services to enable organizations to better and more cost-effectively manage, protect and share information.

Our vision is to create the ultimate information lifecycle management company-to help our customers get the maximum value from their information at the lowest total cost, at every point in the information lifecycle.

The Research Triangle Park Software Design Center is an EMC software design center. We develop world-class software that is used in our NAS, SAN, and storage management products.

Value to EMC

EMC software engineers and architects will use this tool to develop correlations between software change and software defect density. Since software defects impact scheduling, a detailed understanding of the relationships between change and defects will be used to better plan resource allocations and eliminate schedule delays.

Legend for Google_tm Releasing the Power of Engineering Metadata

Project Description

Google is changing the world. From the World Wide Web to photos and documents on your desktop, Google is redefining search capabilities. But for all of its power, there are yet some files "hidden" from Google's goggles.

Many corporate assets are stored within engineering model files. These files contain both geometric data and attribute (textual) data, the sum of which defines the essence of the engineering model. The task is to make this data viewable to Google Desktop.

Legend, a patented technology from Integrated Industrial Information, captures the model file essence and records it into XML files. The XML files contain metadata from the model file and many times contain a thumbnail image of that model. Yet these, too, are not viewable by Google Desktop.

Task One: Bridge the gap. Expand Google's horizon. Allow Google to "see" the corporate assets hidden in the model files. If a thumbnail exists in the XML, it should also be shown.

Task Two: The Google Desktop model file link should display the Model File Properties (metadata) in a tabbed window similar to a Windows File Properties with the following tabs, General, Summary, Attributes, and Structure. A link on the File Properties should Open the model file. Additionally, model files listed in the Structure tab could be links to their Model File Properties.

Insulin Pump Analysis Tool

Purpose

The goal of this project is to add additional functionality to the existing Insulin Pump Analysis Tool that was developed last semester. The intent is to build upon the work of last semester's team, and add additional features that will make the tool more effective.

Background

The most effective treatment for Type 1 Diabetes today is injection of insulin via an insulin pump. The pump must be configured for each patient in order to work effectively. This involves determining levels of insulin required for each time of day, and calculating formulas to determine how much insulin is needed.

Last semester, a team of three students created a prototype tool to calculate the patient's optimal basal rate - the variable rate of insulin infusion needed throughout the day. The tool can currently input data from the insulin pump, and generate a report suggesting new basal rates for each 30-minute period in the day.

Business Justification

When a person with an insulin pump goes to the doctor, the doctor has only a few minutes to review their information and attempt to provide intelligent changes to the programming of their insulin pump. This tool will allow the doctor to easily review the data, and propose effective changes to the insulin pump settings. The final decision is made by the doctor or medical team and the patient.

Project Description

This project will consist of enhancements to the basal rate calculations. It will also include calculations of the optimum formulas to determine how much insulin is needed for meals and to bring down high blood sugar levels. A user-friendly graphical front-end will also be developed.

Project Concept

It is envisioned that this project will be accomplished by students under the auspices of the NCSU Senior Design Project course. The following assumptions apply to this project:

The project will be implemented by a team of four students.

The following will be provided by the sponsor:

• Data files from several patients currently using insulin pumps.
• Subject Matter Experts (SMEs) who will be available to refine requirements and participate in technical reviews throughout the project.
• Feedback from medical personnel.

The expected deliverables include the following:

• Documented design information per NCSU guidelines. At a minimum, design deliverables should include assumptions, structure, and sufficient data to enable others to enhance and extend the software.
• A working prototype of the tool.
• Periodic design reviews to be attended by sponsor.
• Design handoff to sponsor at project completion.
• Delivered code will be the property of sponsor unless otherwise specified in writing.

It is expected that the one-semester project will result in a working prototype of the tool. Documentation and coding practices must be such that the project may be extended to another team for follow-on enhancements or turnover to the sponsor for continued improvements.

Development methodologies are up to the individual team. However, the sponsor encourages the use of agile development methods. Requirements at a concept level are immediately available for the team to study. It is expected that these initial requirements will be refined by the student team in cooperation with the sponsor and SME's prior to starting development. These refined requirements will constitute a formal requirements document or the basis for user stories in an XP development mode.

XML-Based Execution Tools

Purpose

The goal of this project is to create an execution tool that improves the ability to execute a pre-defined upgrade procedure. A Senior Project Team last semester created an authoring tool for creating the XML formatted Upgrade procedure. This semester's task will be to create the execution environment to execute the XML procedures.

This project will focus on creating an execution tool capable of consistently executing a predefined upgrade procedure. The tool should prompt the user for any required input, and provide any necessary output to the user during execution. The tool should maintain a log of all activity during the upgrade process.

Business Justification:

Tekelec engineering and operations personnel execute over 1000 software and hardware upgrades at Customer sites every year. Execution of these upgrades is a combination of Tekelec personnel and Customer self-executed activities.

Current procedure execution presents several challenges:

• Procedures are difficult to execute since the detail involved often leads to misreading the document or skipping steps, especially since most upgrades are performed during the midnight to six AM time frame.
• It is difficult to consistently capture the output generated during the upgrade execution.

Background

Upgrade execution is often error prone. Most upgrades are typically performed between midnight and six AM (the service providers' typical maintenance window). It is not unusual for a technician to accidentally skip a step in the process. To counter this tendency, upgrade procedures have traditionally been written to include a separate verification step for each action, thus adding to the time and complexity of authoring and execution. In the spirit of building the better mousetrap, we have seen that people can, and do, accidentally skip an entire page. Missing a step or series of steps can cause an upgrade abort and invoke a back-out process which is costly for both the Customer and Tekelec.

Project Concept

It is envisioned that this project will be accomplished by students under the auspices of the NCSU Senior Design Project course. The following assumptions apply to this project:

The project will be implemented by a team of four students.

Tekelec will provide the following:

• A Project Manager to act as the interface between Tekelec and the Student Team
• One or more Engineering Mentors to provide input and guidance at various points during the project
• Several Subject Matter Experts (SMEs) who will be available to refine requirements and participate in technical reviews throughout the project
• Opportunity to enable students to participate in actual upgrade generation and execution evolutions to gain real-world experience in the need for this project

The expected deliverables include the following:

• Documented design information per NCSU guidelines. Upon request, Tekelec will provide samples and guidance. At a minimum, design deliverables should include assumptions, structure, and sufficient data to enable others to enhance and extend the software
• A working prototype of the execution tool
• Periodic design reviews to be attended by Tekelec SMEs
• Design handoff to Tekelec engineers at project completion
• All delivered software shall become the property of Tekelec unless otherwise specified in writing.

Expected Skill sets or technologies used include the following:

• Web based application development
• XML

It is expected that the one-semester project will result in working prototypes for the execution tool. Documentation and coding practices must be such that the project may be extended to another team for follow-on enhancements or turnover to Tekelec for continued improvements.

Development methodologies are up to the individual team. However, Tekelec encourages the use of agile development methods. Requirements at a concept level are immediately available for the team to study. It is expected that these initial requirements will be refined by the student team in cooperation with a Tekelec team prior to starting development. These refined requirements will constitute a formal requirements document or the basis for user stories in an XP development mode.

Eagle Measurements Analysis Tool

Purpose

The goal of this project is to create a web-based tool to create HTML-based traffic reports based on existing Eagle Signal Transfer Point (STP) Measurements Platform data.

Business Justification:

The existing Eagle Measurements data is very large and cumbersome to work with. During testing of Eagle Measurements, the testers must analyze large amounts of traffic and measurements data in order to verify the functionality of the system. This takes a lot of time, and can be error-prone. A tool is needed that will simplify this task, and allow the testers to easily view traffic reports for comparison with information from the traffic generation tools. This tool could also be used by Tekelec's customers for generating traffic reports in a user-friendly manner.

Project Description

This project will involve the creation of a tool that will get measurements data from the Eagle STP, and create a web-based interface to generate useful reports from the data. This will include the following high level steps:

• Define the schema for the measurements data.
• Create mock-ups of the desired reports based on input from Tekelec.
• Map the existing Eagle CSV files to the schema.
• Map the schema to the desired reports.
• Working with a Report Generator provided by Tekelec, generate the desired reports. Report definition will be done using the Python programming language.

Project Concept

It is envisioned that this project will be accomplished by students under the auspices of the NCSU Senior Design Project course. The following assumptions apply to this project:

The project will be implemented by a team of four students.

Tekelec will provide the following:

• A Project Manager to act as the interface between Tekelec and the Student Team.
• One or more Engineering Mentors to provide input and guidance at various points during the project.
• Subject Matter Experts (SMEs) who will be available to refine requirements and participate in technical reviews throughout the project.

The expected deliverables include the following:

• Documented design information per NCSU guidelines. Upon request, Tekelec will provide samples and guidance. At a minimum, design deliverables should include assumptions, structure, and sufficient data to enable others to enhance and extend the software.
• A working prototype of the tool.
• Periodic design reviews to be attended by Tekelec SMEs.
• Design handoff to Tekelec engineers at project completion.
• Delivered code will be the property of Tekelec unless otherwise specified in writing.

Expected Skill sets or technologies to be used include the following:

• JAVA
• J2EE
• Python
• MySQL

It is expected that the one-semester project will result in a working prototype of the tool. Documentation and coding practices must be such that the project may be extended to another team for follow-on enhancements or turnover to Tekelec for continued improvements.

Development methodologies are up to the individual team. However, Tekelec encourages the use of agile development methods. Requirements at a concept level are immediately available for the team to study. It is expected that these initial requirements will be refined by the student team in cooperation with a Tekelec team prior to starting development. These refined requirements will constitute a formal requirements document or the basis for user stories in an XP development mode.

Xplanner Enhancements

Purpose

The goal of this project is to enhance the functionality and usability of XPlanner, an open source tool used to track Extreme Programming (XP) software development projects.

Business Justification:

Tekelec currently uses XPlanner to plan and track progress for all projects developed using the XP methodology. XPlanner is used extensively during planning meetings. While XPlanner is a very useful tool, there is a need for a more user friendly front-end that will allow more efficient data entry and modification, and better status reporting.

Project Concept

It is envisioned that this project will be accomplished by students under the auspices of the NCSU Senior Design Project course. The following assumptions apply to this project:

The project will be implemented by a team of four students.

Tekelec will provide the following:

• A Project Manager to act as the interface between Tekelec and the Student Team.
• One or more Engineering Mentors to provide input and guidance at various points during the project.
• Subject Matter Experts (SMEs) who will be available to refine requirements and participate in technical reviews throughout the project.

The expected deliverables include the following:

• Documented design information per NCSU guidelines. Upon request, Tekelec will provide samples and guidance. At a minimum, design deliverables should include assumptions, structure, and sufficient data to enable others to enhance and extend the software.
• A working prototype of the XPlanner enhancements.
• Periodic design reviews to be attended by Tekelec SMEs.
• Design handoff to Tekelec engineers at project completion.
• Delivered code will be the property of Tekelec unless otherwise specified in writing. Tekelec is open to considerations of sharing this product with NCSU and/or release under GPL.

Expected Skill sets or technologies used include the following:

• JAVA programming language experience

It is expected that the one-semester project will result in a working prototype for the XPlanner enhancements. Documentation and coding practices must be such that the project may be extended to another team for follow-on enhancements or turnover to Tekelec for continued improvements.

Development methodologies are up to the individual team. However, Tekelec encourages the use of agile development methods. Requirements at a concept level are immediately available for the team to study. It is expected that these initial requirements will be refined by the student team in cooperation with a Tekelec team prior to starting development. These refined requirements will constitute a formal requirements document or the basis for user stories in an XP development mode.

Documentation Front End Analysis Tool

Purpose

The goal of this project is to create an electronic front end for customer documentation that will allow the user to select the features they are using, and only look at relevant documentation. This project would be a proof-of-concept, not a full implementation of a complete set of product documentation for any specific project.

Business Justification

The existing Customer Documentation set for the Eagle Signal Transfer Point (STP) is over 12,000 pages long. Much of this documentation is related to specific features that are not used by all customers. This makes it difficult for the customers to quickly find the information that they need. A tool is needed that will allow the customer to specify the features that they are using, and allow them to look at the subset of the documentation that is applicable to that feature list.

Project Description

This project will involve creating a method of tagging information in the documentation set in such a way as to allow the software to filter out unnecessary sections of the document for each specific customer's needs. This capability should be generic enough to use for documentation of any product.

Project Concept

It is envisioned that this project will be accomplished by students under the auspices of the NCSU Senior Design Project course. The following assumptions apply to this project:

The project will be implemented by a team of four students.

Tekelec will provide the following:

• A Project Manager to act as the interface between Tekelec and the Student Team.
• One or more Engineering Mentors to provide input and guidance at various points during the project.
• Subject Matter Experts (SMEs) who will be available to refine requirements and participate in technical reviews throughout the project.

The expected deliverables include the following:

• Documented design information per NCSU guidelines. Upon request, Tekelec will provide samples and guidance. At a minimum, design deliverables should include assumptions, structure, and sufficient data to enable others to enhance and extend the software.
• A working prototype of the tool.
• Periodic design reviews to be attended by Tekelec SMEs.
• Design handoff to Tekelec engineers at project completion.
• Delivered code will be the property of Tekelec unless otherwise specified in writing.

It is expected that the one-semester project will result in a working prototype of the tool. Documentation and coding practices must be such that the project may be extended to another team for follow-on enhancements or turnover to Tekelec for continued improvements.

Development methodologies are up to the individual team. However, Tekelec encourages the use of agile development methods. Requirements at a concept level are immediately available for the team to study. It is expected that these initial requirements will be refined by the student team in cooperation with a Tekelec team prior to starting development. These refined requirements will constitute a formal requirements document or the basis for user stories in an XP development mode.

OPOS Simulators

Project Description

Fujitsu Transaction Solutions 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 Nordstrom and Payless Shoe Source are able to customize.

The proprietary software product that provides the code base for Fujitsu software solutions is called iStore™. iStore™ implementations use real devices appropriate to the retail market, such as a cash drawer, receipt printer, barcode scanner, etc. When designing and implementing custom point-of-sale applications based on iStore™, it is more convenient for developers to attach simulated devices. The OPOS standard sets out specifications for these devices. Software simulators must mimic physical devices in minute detail so that iStore™ code that communicates with a device cannot tell the difference between a real device and a simulated device.

The goal for the Spring 2005 senior design team is to build on an existing design and implementation for OPOS Device Simulators created by a previous senior design team (Fall 2004) and create additional OPOS Device Simulators. The team will use state of the art development tools such as Visual Studio.Net, including C#, Visual Basic.Net, Windows XP/2000.

Radio-Triggered Wake-Up for Wireless Sensor Systems

The overall goal of this project is to improve power management for processing elements of a battery-powered wireless sensor system and demonstrate that such a system can contribute to improving power management in wireless sensor systems. In a wireless sensor system, synchronization between various processing elements is problematic because the commonly used power saving technique is to place the system into a sleep state, turning off all subsystems except a timer to drive the wake-up mechanism. This approach introduces timing synchronization problems in a system comprising many (e.g., hundreds) of independent processing elements. The approach of this project is to borrow an idea from Radio Frequency IDentification (RFID) devices. Passive RFID devices contain no internal power source, but rely instead on power generated by receipt of an external RF signal to produce an RF signal response. The idea behind this project is to adapt the RFID concept of extracting incoming RF power, but, instead of using this extracted power to generate an RF response, to use this extracted power to generate an interrupt signal to a microprocessor. If successful, such a circuit could significantly reduce the complexity of power management in a wireless sensor system. The need for timing synchronization would be eliminated; absolute power drain would be minimized. Designs for such a circuit have been published in the literature. Ultimately, such an RF-based wake-up mechanism would be an integral part of a proposed new wildlife tracking system, a prototype of which is currently under development. Faculty, staff, and students from the NC State Computer Science Department have been working on the problem of defining a better computer system architecture for wildlife tracking. Several computer science senior design projects have been conducted to explore hardware and software available to create such a system . As a result of these projects, prototype components of a new tracking architecture have been built using Berkeley "Mote" devices, available from Crossbow Technologies. We would like to add a more efficient power management capability to this toolbox.

Circuit designs for radio-triggered wakeup have been published. The specific goal of this project is to challenge senior design students from CSC and ECE to refine this design and implement prototype hardware and software necessary to demonstrate radio wakeup functionality. Accomplishing this in a one-semester project is an ambitious goal, but we believe progress can be made.

Computer Science technologies: Background or interest in C, Linux, embedded systems, wireless software architecture and applications.

TIM Test Toolkit

About Itron

Itron is a leading technology provider and critical source of knowledge to the global energy and water industries. More than 3,000 utilities worldwide rely on Itron technology to provide the knowledge they require to optimize the delivery and use of energy and water. Itron creates value for its clients by providing industry-leading solutions for electricity meter data collection; energy information management; load forecasting, and enterprise and residential energy management. Company website: www.itron.com.

Problem Statement

This project involves developing several tools to test Itron's Translation Interface Modules or TIMs. A TIM interfaces numerous Itron software applications to a metering device. Typical metering devices in your home are the electric, water, and gas meters; these are often optically probed with a hand-held computer. In the commercial & industrial environment, similar metering devices are more sophisticated and require remote interrogation via modems, RF, or network based communications.

The utilities require meter information to monitor & maintain their infrastructure (generators, substations, transmission & distribution lines, etc.) They also require this information to bill their customers. The utilities want to monitor how much & when energy is used by their customers. They also want to know when events occur; things like when power outages occurred or when someone tampered with a meter. All this information is recorded in the metering devices. The TIM allows the software applications to extract these various types of data from a metering device via a common protocol. TIMs also allows the applications to write information to a metering device.

Test tools are desired to increase efficiencies in developing, testing, & supporting TIMs. The project deliverables may include (to be adjusted in consultation with the student team):

• DC-232 Simulator. A tool that reads a debug file (as input) and simulates the communications between the TIM & the metering device. This allows the TIM to run without actually communicating with the metering device.
• TIM Launcher. A tool used to launch a TIM in a development or test environment.
• Request File Wizard. This wizard will aid in the creation of test request files consumed by the TIM during execution.

Technical Considerations

TIMs operate in three environments -- Win32, WinCE, and DOS. At a minimum, the test library must operate in the Win32 and WinCE environments. DOS support is optional, but desired. The programming language will be C++. To integrate the finished product with Itron's existing development environment, the following tools should be used: Visual C++ 6.0 in Microsoft Visual Studio 6.0 for Win32; Embedded Visual C++ 4.2 for WinCE, and Visual C++ 1.52 for DOS. The project will be implemented as a Dynamic Link Library (DLL) in Win32 and WinCE. DOS execution requires a static library to link with the TIM.

Work-In-Progress Monitoring

MEMS (Micro Electrical Mechanical Systems) were first developed in the 1970s and then commercialized in the 1990s. MEMS make it possible for systems of all kinds to be smaller, faster, more energy-efficient and less expensive. In a typical MEMS configuration, integrated circuits (ICs) provide the "thinking" part of the system, while MEMS complement this intelligence with active perception and control functions.

MEMS are usually divided into two categories -- those devices that detect information, called microsensors, and those devices that can respond to information, or act, called actuators. Microsensors gather local information including, for example, thermal, biological, chemical, optical and acoustical input. The electronics of the devices can then process the information and may direct actuators to respond and control the environment (e.g. by moving, pumping, filtering) based on an intended, designed instruction.

MEMSCAP provides innovative solutions based on micro-electromechanical systems, or MEMS. The company enables customers in high-growth markets to incorporate strategic MEMS technology into their systems as a means of addressing critical technical and cost challenges. MEMS are microscopic mechanical systems that combine mechanical, optical and fluidic elements with electronics on a single integrated circuit.

MEMSCAP currently manufactures a wide variety of MEMS products and all product manufacturing at MEMSCAP is controlled using a proprietary software package used to monitor and schedule all work in progress (WIP). This WIP monitoring software utilizes a GUI front end to a SQL Server database. MEMSCAP has a need to migrate the current GUI to a web based GUI, add additional report capability and optimize database transactions used within the system. The preferred implementation of the new system will require use of Visual Studio .NET, ASP.NET and Microsoft SQL Server.

The goal of the Sixth Annual Computer Society International Design Competition (CSIDC) is to advance excellence in education by having student teams design and implement computer-based solutions to real-world problems. The theme of this year's CSIDC is Added Value: Turning Computers Into Systems. Teams are encouraged to take a PC, laptop, hand-held computer (or similar device) and use additional low-cost hardware/software to create a computer-based solution to a problem that is socially valuable. Add-on cost must be less than $400 (this cost will be paid by the Senior Design Center). First Prize is $15,000 to be distributed among the students on the team. Total of all prizes to be awarded to students is $37,000.

For more information check http://www.computer.org/csidc/