Projects – Fall 2006

The Urban Challenge

Project Description

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.

MP3 Profiler

Project Description

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.

Testing

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

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:

Useful ID3 information: http://jicyshout.sourceforge.net/oreilly-article/java-streaming-mp3-pt2/java-streaming-mp3-pt2.html

Useful SOAP tutorial: http://www.oreilly.com/catalog/javaxml2/chapter/ch12.html#84863

Deliverables

Required Deliverables

• Source code, project files and build files for downloadable client
• Source code, project files and build files for server
• Unit tests for the client component and server components
• Compiled downloadable client binary
• Deployable J2EE WAR file containing all web-related functionality (including server-side classes, static web content, client-side classes)
• A small test application that demonstrates the SOAP/RPC web service access
• User Documentation.

Bonus Deliverables

• Support all well-known ID3 tag formats: 1.0, 1.1, 2.2, 2.3, 2.4. (From Wikipedia, the free encyclopedia: ID3 is a metadata container most often used in conjunction with the MP3 Audio file format. It allows information such as the title, artist, album, track number, or other information about the file to be stored in the file itself.)
• Efficiently providing for incremental rescan of a hard drive and only providing deltas to the server
• Ability to rescan on a schedule and report results to the server behind-the-scenes with no user-intervention
• A web page to edit a user profile
• if current user is an admin, admin can change privileges and reset password for any user
• if current user is an end user, only his/her own profile can be modified
• For all columnar reports, make the report sortable by clicking on each column header title to sort by that column while also being paged
• For pictorial metadata, such as an album cover photo, provide a way to show these in the Track Detail page
• Refactor the database to allow a particular track to exist only once across multiple users if the track is in fact identical
• A web page that allows an administrator to delete a user and all related information

Implementation Challenges

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

Project Description

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:

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:

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:

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.

Requirements

• Collect data from several computer systems at set intervals (>= 5 seconds) based on type of system being monitored and user input.

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.

• Aggregate data from various sources including but not limited to the above collected data into a single structure that includes all relevant data.
  
  It is important to be able to add additional data, such as benchmark data, at this point. The design should allow an unspecified number of additional data files to be imported.
• Output the aggregated data to a standard format usable by various third party analysis tools.
  
  The output of this performance monitoring tool will need to be accessible by a wide variety of third party tools for analysis. One common example is Microsoft Excel, which for example can understand the standard CSV format.
• Impose minimum or fixed load on monitored system

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.

Deliverables

• Requirements definition document
• Design specification(s) for construction of the actual software
• Test plan (developed in conjunction with EMC engineering – to be executed by EMC engineering)
• Weekly written status reports on progress
• Source code and scripts for the actual tool(s), any tool or test software sources, and documentation (user’s guide) for the implementation
• Overview presentation and written report outlining the requirements, the methodology, software components, implementation, results, and lessons learned based on the work done

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.

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 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.

LocationCENTER

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.

Goals

1. The primary objective of the SARA Portal Project is to implement a portal solution to replace the static web pages of SARA
2. The second major objective of the SARA Portal Project is to make the portal-based SARA content both self-maintaining and easily modifiable
3. The third major objective of the SARA Portal Project is to implement beneficial portal technology features not available in old static web pages
4. A fourth major objective of the SARA Portal Project is to introduce to OSA users the concept and methods of shared user-maintainable websites and collaboration via web pages, and to successfully seed a modernizing change in the organization’s approach to sharing information

Deliverables

1. Portal Planning Document (output): The Portal Planning Document will lay out the major features and navigation of the portal site.
2. Implementation (action): Copy / move content into to portal in a phased approach.
3. Branding (action): Create and implement the necessary graphic files and style changes that would “brand” the portal to give it a unique logo, icons and appearance indicative of the Office of the State Auditor’s intranet.
4. Testing Team (action and output): Recruit an audit team and an audit manager to test the team collaboration features and to get feedback on the organization of the overall portal site.
5. Salesmanship (output): Create a five to ten minute Windows Media presentation (.WMV) which would be used to “sell” the benefits of the new portal technology to OSA users.
6. Training Plan (output): Document an outline of training content for general users which leverages the integration of Microsoft Office 2003 with SharePoint Portal Server 2003 and emphasizes the ease of maintaining content directly on the portal pages. The amount of content would span about two to four hours.
7. Backup / Restore Plan (output and action): Document and test a portal backup and restore plan.
8. Assist Content Owners (action): Assist the content owners in learning to view, edit and update their information during the phased deployment.

Constraint

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.

Security

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.