- About Us
- For Students
Click on a project to read its description.
The Urban Challenge
Defense Advanced Research Projects Agency (DARPA) has announced a new Grand Challenge -- the Urban Challenge. The previous Grand Challenge was to construct an autonomous vehicle that could navigate an off-road course (approximately 130 miles) and demonstrate the vehicle’s capability in a “race” across the desert. This race occurred October 2005 and was successfully completed by 5 entries. The new Urban Challenge focuses the venue on a mock urban setting, requiring autonomous ground vehicles to merge into moving traffic, navigate traffic circles, negotiate busy intersections and avoid obstacles.
Insight Racing, a local team that built a vehicle that qualified for the last grand Challenge, is planning an entry for the Urban Challenge. Insight's entry into the last Grand Challenge completed 28 miles of the 132-mile course, placing them 12th out of 23 entries -- a very respectable effort.
The proposed project is to create a sub-system for the urban autonomous vehicle that will perform path planning and provide visualization of vehicle progress. Path planning requires construction of navigation commands to follow a course provided by DARPA that also executes a given mission, i.e., requires the vehicle to drive to particular points in a defined order.
The objective of this project is to build software that can profile an MP3 collection on a client's hard drive and report that metadata to a centralized server for storage in a database. The solution will require a downloadable scanning client, a server for receiving metadata information, a web server for providing browser based functionality to manage and access the stored information, and a web service for programmatically accessing the managed information.
It is important to note that all details of this project are open for discussion and the best solutions often materialize from such open forums where everyone has an opportunity to contribute their individual ideas and expertise. We anticipate that a requirements document will be refined during the first few weeks of the project as a team effort.
Each aspect of the solution should be tested and validated to ensure that the solution does what it was designed to do. Testing should be automated and incorporated into the build process such that the solution is known to pass all test cases each time that binaries are created.
Unit testing can be used to verify that every method of every class performs the desired function. It is useful to test for fringe cases such as handling of nulls, negative numbers, conflicting arguments, empty strings, very long strings, just out of range values, excessively out of range values, NaN real numbers, bad dates, etc. JUnit is a popular framework for conducting such unit tests in an automated fashion
Http and Servlet Testing
Http and Servlet Testing can be used to verify that a web page delivers the intended information and that form submissions are processed correctly and produce the intended result, whether it be delivering the correct information, persisting information correctly to a database or otherwise modifying or presenting information. HttpUnit and ServletUnit are popular frameworks for conducting such testing in an automated Fashion.
Recommended Development Environment and Technologies
The following commercial-quality cross-platform solutions, all available for free, are recommended for this project:
|J2EE servlet container||tomcat||http://tomcat.apache.org|
|HTTP web server||tomcat||http://tomcat.apache.org|
|Web service protocol||SOAP / XML||http://ant.apache.org|
|Servlet testing||HttpUnit / ServletUnit||http://httpunit.sourceforge.net|
|MP3 ID3 metadata||ID3||http://www.id3.org|
Useful SOAP tutorial: http://www.oreilly.com/catalog/javaxml2/chapter/ch12.html#84863
It is non-trivial to ensure that an Object-Relational Mapping (O/RM) is fully transactional and thread safe under all circumstances. Real world situations, such as a user repeatedly clicking a 'Submit' button out of impatience, easily wreak havoc with database persistence, atomicity and thread safety. An O/RM is a black box that hides implementation details. This makes it difficult to diagnose and fix such problems, much less avoid them in the first place.
It is non-trivial to ensure that no path through a web page or a web service request can accidentally gain unauthorized access to data. This requires a well-planned testing strategy.
Crispin RapidCollector and IssuesTracking Integration
About Crispin Corporation
Founded in 1997, Crispin Corporation is a leading worldwide provider of broadcast automation software, equipment, services and support. Modular in design, Crispin's flexible systems help small to large-scale facilities develop and customize cost-effective solutions designed to connect elements from existing and new systems into one, integrated, easy-to-use solution. Based in Raleigh, NC, with regional sales offices located throughout the United States, Crispin offers automation solutions to over 360 broadcast facilities worldwide. For more information, contact Crispin at (919) 845-7744 or visit us on the Web at http://www.crispincorp.com
RapidCollector is a utility that allows Crispin customers to quickly collect application and system log files from Crispin software and deliver these log files to Crispin for analysis whenever there has been an on-air error at a customer’s television station. A Customer Server records the issue into the IssuesTracking database. The log files are analyzed by Crispin technical support to determine the cause of the error and each issue is assigned to tech support, a programmer, or a systems analyst, as appropriate. The goal of this project is to seamlessly integrate the RapidCollector and IssuesTracking systems so that a customer receives immediate feedback when an issue has been logged and assigned a tracking number. A customer must be able to view the status of all submitted issues/cases and even receive software updates. The project requires a combination of both C++ and web programming via PHP and SQL.
Network Attached Storage (NAS) Performance Monitor
Background. In characterizing the performance of any given NAS environment there are numerous components that could impose limits on the performance of the whole system. The purpose of the tool proposed in this document is to monitor the various components in the environment so that the factors impacting performance can be identified.
Objective. We need a tool that can be invoked from a single location that will monitor multiple types of system components, return the results to the invoking system, and store the results for future analysis. The tool should allow the data collection rate to be configured by the user, up to the minimum polling interval for the system. The tool must be designed to impose a minimum or fixed load on the system being monitored.
Example. Benchmarks are a common method used to distil the performance of a system down to just a few numbers to simplify comparisons between configurations. In a typical Network Attached Storage (NAS) environment there may be multiple independent systems that contribute to the perceived performance in a given test; examples include network routers and switches, storage arrays, the systems running the test, and file servers. Please see the example below for an idea of how these systems are related.
You can easily see that a request to access data has to go through several systems. On these numerous computer systems there are commands that can be used to determine the activity of various sub-systems and components at given times, or during given time intervals. With multiple independent systems that impact performance, it becomes necessary to monitor several systems simultaneously, resulting in several sets of data. The first step in this project is to create a monitoring tool capable of collecting data from the various systems and returning the resulting data to a central location in a common format for further processing.
These statistics can be generally displayed in a table like the one below:
|Statistic W||Statistic X||Statistic Y||Statistic Z|
Given multiple systems there will be multiple tables. The second part of the project is to aggregate the data from multiple tables into a single table that is suitable for analysis.
The multiple data tables collected may look something like this:
|Time||CPU 1||Memory 1|
|Time||CPU 2||Memory 2|
As demonstrated in the above tables, we cannot always ensure that the time index, or any other common index, from one system will match exactly with the index from another system. In this example it is clear that time is the only common index, so it will be used for this example.
Given that the time values do not match, we cannot simply combine rows because it would yield a table with lots of missing values, which would not be suitable for most analysis tools. The data aggregation program will take the tables above and determine the best method to combine them into a single table. In this instance it would generate something like the table below:
|Time||IOPS||Throughput||CPU 1||Memory 1||CPU 2||Memory 2|
We would like to see a team from NCSU implement the data collection portions of the project for EMC Celerra and EMC Clariion systems; and to implement the data aggregation portion of the project.
For the Senior Design project the data collection would be limited to EMC Celerra and EMC Clariion systems; but the design should not limit our ability to add further systems at a later time.
Ideally the data will be returned to a database that can store results from several distinct systems, however this is not required and any method for storing the data so that it can later be used in the aggregation tool will satisfy the requirement.
Characterizing the load on a given system is inherently subject to the observer effect. Every effort should be made to characterize or minimize the impact that this effect has on the data being reported.
Value to EMC
EMC software developers and performance engineers will use this tool to study blended performance data from complicated performance setups. The tool with provide them a means to evaluate this data more quickly and more importantly see time correlated trends that are easily missed when looking through individual files.
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 out 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.
EMC where information lives.
Fujitsu Transaction Solutions (FTXS) is one of the top three suppliers of retail systems and services worldwide. FTXS usage of Service Oriented Architecture (SOA) creates a high performance yet open platform that retailers as diverse as Nordstroms and Payless Shoe Source are able to customize.
The team will create a new product called LocationCENTER. LocationCENTER is used to locate items in different stores. The team will use state-of-the-art development tools such as Visual Studio.Net.
The following is a typical scenario:
Customer is trying to locate an item in the store. The customer does not see the item on the sales floor. The customer asks a sales associate if the store has any more of the item. The sales associate checks the store inventory and determines that the item is not in stock. The customer asks the sales associate if any of the other local stores have the item in stock. The sales associate calls all the local stores to determine which store has the item in stock. If a store has the item in stock, the other store pulls the item and reserves it for the customer. The sales associate can also provide directions to the store to the customer.
To provide better customer service and reduce time required by sales associate, much if this process needs to be automated.
(Technologies Used: C#, ASP.Net, Windows XP)
SARA Portal Project
Statement of Problem
The Office of the State Auditor (OSA) has, for well over a decade, utilized a static-pages website as an intranet to provide a presentation for its internal information. This top-level intranet website is named “SARA” (State Auditors’ Resource Area). OSA proposes an intranet website rebuild project to a CSC Senior Design team at NCSU.
The OSA would implement the portal using Windows SharePoint Services (WSS) and Microsoft SharePoint Portal Server 2003 (SPS), leveraging objects, properties, and security information from our Windows Active Directory, and content from SARA and the Novell S: drive file share.
Flexibility & Discretion
The Office of the State Auditor requests that the E-Partners project team research, suggest, document and implement the best features of the aforementioned portal technologies for repositioning OSA’s internal business information (SARA, S: drive) and collaboration practices. Such action will include the configuration, implementation and resolution of configuration problems during the project, as needed. The OSA purposefully grants flexibility to the E-Partners team as to the particulars of the implementation.
This project may require that the project team be given access to OSA’s trusted network environment. This may require that the project members accede to a security disclaimer which stipulates appropriate use of OSA’s infrastructure and its governing security policies.
Online RSS Reader
Really Simple Syndication (RSS) is an XML-based standard for syndicating web content such as blogs, news, website updates, podcasts, and just about any other web-based content on the internet today. An RSS XML feed can contain the actual content or the metadata describing the content. RSS readers and feed aggregators can pull this XML file from sites all over the internet and display the information in one place. The end result is an easy way for users to subscribe to websites and news feeds from many sources and read the information in one place similar to an interface like reading newsgroups or email.
This project will be to design and implement a prototype web based RSS reader capable of supporting individual subscription lists for multiple users. It will leverage semantic markup and CSS to format the information. Technologies to consider using are Java/JSP or PHP as well as a database (MySQL). The prototype should be designed with scalability in mind and will tackle several problems not solved by current feed readers such as passing authentication data to secure RSS feeds.
Several examples of this technology can be seen in client based RSS readers such as Mozilla Thunderbird or Firefox's Sage extension as well as current online web based implementations like bloglines.com and google.com's reader (google.com/reader). You can learn more about the history of RSS at http://en.wikipedia.org/wiki/RSS_(file_format)
This project will be flexible in its design and open to innovative approaches to solving the problem.