SYST 798 PARKme System Technology Strategy
PARKme System
Technology Strategy
George Mason University
SYST 798, Prof. Speller
Craig Emmerton
Earl Morton
Shaun McDonald
David Richards
Nikki Torres-Avila
Table of Contents
1.0 INTRODUCTION 3
1.1 Background 3
1.2 Applicable Documents 3
1.3 Scope 3
1.4 Relationship to Overall Business Strategy 4
2.0 STRATEGY 4
2.1 Technology Readiness Levels 4
2.2 Intellectual Rights 6
2.3 Proprietary Data 12
2.3.1 Proprietary Software 12
2.3.2 Proprietary Data 12
2.4 Hardware Upgrades 12
2.5 Software Upgrades 13
2.6 Modular System 13
3.0 EXTERNAL FORCES 14
3.1 Summary of Changes Driven from Outside Organization 14
3.2 Rising Expectations of Users 15
3.3 Securing the System from Threats 15
3.3.1 Securing the Hardware 15
3.3.2 Securing the Network 15
3.3.3 Securing the Server 15
3.3.4 Securing the Software 16
APPENDIX A – ACRONYMS 17
1.0 INTRODUCTION
1.1 Background
Finding a parking spot on the George Mason University campus can be a frustrating and time consuming process. Students and faculty risk being late for class and visitors to meetings.
The idea for the PARKme system came when reading an article in the New York Times on July 12, 2008 about the parking system being implemented by the city of San Francisco. San Francisco is using a wireless sensor network and street sign displays to inform drivers of open parking spaces on city streets. The system San Francisco is designing can also alert users via cell phones.
The PARKme system will alleviate the frustration associated with parking in large parking areas such as a college campus. The system will provide drivers with the location of the best available parking spaces at the time they enter the parking complex. The PARKme system is modular in design to allow easy expansion as parking complexes grow in size.
The technology utilized by the PARKme system will be commercial-off-the-shelf (COTS) hardware and software that will be integrated together to form complete system. The lone exception to using COTS is the software that utilizes the sensor status data to calculate available parking spaces. This software will be exclusively developed for the PARKme system development company (see section 3.3.1 Proprietary Software). The PARKme system developers will only use currently available technology within the scope of the system.
1.2 Applicable Documents
DOD (2006), Defense Acquisition Guidebook
Mankins, John C. (April 6, 1995), “Technology Readiness Levels” (www.hq.nasa.gov/office/codeq/trl/trl.pdf).
PARKme Business Case
1.3 Scope
The scope of this system is focused on the George Mason University campus parking lots and parking garages. This system is modular in design and could therefore be marketed to a larger section of the market once the design has been proofed out. As this system is modular in design it can be proofed out on a much smaller scale than the entire campus. The intent for this system is to provide a quality system to handle parking for the entire campus but to prove the concept only 2 parking spaces are needed along with the hardware and software of the PARKme system. Primary customer has identified the major areas of concern that should be the focus of the initial delivery of such a system. The University has a ring of parking lots that surround the immediate campus and are the most heavily used and provide the most resource contention. As the major parking shortage is for GMU students the focus should be on student/general lots that are nearest to the campus. Lots farther away from campus have a much higher availability and are usually not competed for. Although initial entrance into this market is focused on GMU as the primary stakeholder other market and business opportunities will be identified as well as the technology strategy employed to protect property rights and the financial analysis to show the way ahead.
1.4 Relationship to Overall Business Strategy
The PARKme Technology Strategy was developed in parallel with the PARKme Business Case. The technology and architecture being used in the PARKme system helped formed the business strategy. The PARKme system was developed with a modular design in from the beginning. This enables the system to be easily implemented in different types of parking facilities. This becomes a key selling point of the system. The growth of the PARKme system as a business will depend on successfully implementing the system at George Mason University. After successful implementation, investors can see how the system can be expanded and modified for any particular parking facility.
The PARKme system heavily utilizes COTS components to save on research and development costs. The core cost of the PARKme system will be in software development and implementation. Since the system was designed to be modular from the initial concept, the software development cost will be minimal after the initial development. Only minor software updates will be needed to configure the system for any particular setup. Installation costs will also decrease over time as the install team becomes more experienced installing and setting up the system. Utilizing COTS components enables the PARKme system to significantly cut the life cycle costs of the system.
The technology being implemented in the PARKme system allows the project team to sell the system to many different types of facilities. Facilities such as hospitals, shopping malls, and airports can choose human interface components that best fir their facility layout. This will increase the market size beyond a University campus. The modular design of the PARKme system and the use of COTS components helped shape the business case for the project.
2.0 STRATEGY
2.1 Technology Readiness Levels
John C. Mankins in his white paper titled, “Technology Readiness Levels” (April 6, 1995) describes Technology Readiness Levels (TRLs) as a “systematic metric/measurement system that support assessments of the maturity of a particular technology. The idea of using TRLs came out of NASA space technology planning. TRL levels of a technology are normally shown on a thermometer graphic such as the figure below:
Figure 2-1: Thermometer Graphic of TRL Levels
The nine levels of TRLs start from TRL 1, the lowest level of technology maturation, to TRL 9, the highest level of technology maturation. Following is a brief description of each technology level (Source: DOD (2006), Defense Acquisition Guidebook):
· TRL 1 – The lowest level of technology maturation. Scientific research begins to be translated into applied research and development.
· TRL 2 – Invention begins. Once basic principles are observed, practical applications can be invented. The application is speculative and there is no proof or detailed analysis to support the assumption.
· TRL 3 – Active research and development initiated. This included analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology.
· TRL 4 – Basic technology components are integrated to establish that the pieces will work together. This is relatively “low fidelity” compared to the eventual system.
· TRL 5 – Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so that the technology can be tested in a simulated environment.
· TRL 6 – Representative model or prototype system, which is well beyond the breadboard tested for TRL 5, is tested in a relevant environment. Represents a major step up in a technology’s demonstrated readiness.
· TRL 7 – Prototype near or at planned operational system. Represents a major step up from TRL 6, requiring the demonstration of an actual system prototype in an operational environment, such as in an aircraft, vehicle, or space.
· TRL 8 – Technology has been proven to work in its final form and under expected conditions. In almost all cases, this TRL represents the end of true system development.
· TRL 9 – Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation. In almost all cases, this is the end of the last “bug fixing” aspects of true system development.
The TRL of all technology integrated into the PARKme system must be at least on level 7 on the TRL scale with the goal of TRL 8. The technology must be near ready for an operational system. The PARKme system utilizes current technology and integrates it into a System-of-Systems environment. The underlying technology must be ready to be integrated into this environment, as it will not be cost feasible to wait for the technology to mature to TRL 7.
The PARKme system shall utilize TRLs to assist in risk management of developing the system. Any proposed technology to be used in the PARKme system must meet TRL 7 or the program risks schedule and cost increases.
2.2 Intellectual Rights
The PARKme system is comprised of components that will be purchased for use to be integrated in the system. The individual components’ rights belong to the patent holder and/or company that manufacturers the component.
The PARKme system will apply for a patent for the concept of the parking locator system. The first step before applying for a patent was to do a search of patents for similar systems. The PARKme team accessed the United States Patent and Trademark Office (USPTO) via Google Patent Search to perform this search. The results of the search included four similar systems.
The first result was US Patent Application No. 10/012,750 filed on December 7, 2001. Titled, “Automated Space Availability Coordinator,” the patent application was filed by George A. Drennan. A summary of the system is as follows: “Implement an automated available unit locator for a multiple unit network comprising an occupancy sensor for determining an occupancy status of each unit in a multiple unit network.” The patent application describes a high-level system and uses a parking facility as an example of utilizing the idea. See Figure 2-2 below for an example of the system.
Figure 2-2: Drawing of the Automated Space Availability Coordinator
This idea does include the space sensor and describes a locator device for locating a space. The parking example described in the patent application includes lift gates and access stations. The access stations examples includes airports where the user could enter the airline they are flying and the system would give them the closest available parking space. This is very similar to the PARKme idea of a kiosk helping the driver find a parking space. This patent application would have to be further analyzed by a patent attorney to see if there are enough differences between this system and the PARKme system to allow the PARKme team to file a patent without infringing on this patent application. It should be noted that this patent application is still awaiting approval for a patent.
The second result was US Patent Application No. 09/736,355 filed on December 14, 2000. Titled, “Method and Systems for Space Reservation on Parking Lots with Mechanisms for Space Auction, Over-booking, Reservation Period Extensions, and Incentives,” the patent application was filed by Andrew J. Dillon. A summary of the system is as follows: “A computer-driven reservation system for reserving spaces in a parking facility at an airport terminal. System comprised of a central server, database of locations, associated spaces, and one or more computer terminals. A GUI for receiving customer reservations and an interlinked network via a WAN such as the Internet.” Figure 2-3 shows a concept drawing of the system.
Figure 2-3: Concept Drawing of Reservation Patent Application
This patent application has several capabilities contained within the PARKme system such as a central server, database of locations, computer terminals, and interlinked via a WAN. This patent application describes a reservation and auction system and the PARKme system is not designed to reserve or auction parking spaces. The PARKme system would not infringe on this patent application if the application for a patent were approved.
The third result was US Patent Application No. 11/022,442 filed on December 22, 2004. This patent application was approved and is Patent No. US 7,289,903 B2. Titled, “Methods, Systems, and Computer Program Products for Implementing a Locator Service,” the patent application was filed by Maria Adamczyk and Edward Silver. A summary of the system is as follows: “Receiving object identification information from a mobile object and receiving location identification information from the mobile object. The location identification information indicates the presence of the mobile object at a location. Also, includes associating the object identification information with the location identification information and creating an occupancy record including result of the associating. Storing the occupancy record in a storage device.” A concept of the patent is shown in Figure 2-4.
Figure 2-4: Concept Drawing of Locator Service Patent
This patent has several components similar to the PARKme system such as an occupancy database, network, and object identification. The key difference between the patented system and our system is our system does not depend on receiving information from the vehicle. The patented system requires obtaining object identification from the vehicle, which is not required in the PARKme system. The patent system has each vehicle containing a Wi-Fi or GPS card to identify itself. This system also details collecting parking fees, which is also not part of the PARKme system. The PARKme system has some similarities with this patent but enough differences that the PARKme team feels a patent attorney could argue that the PARKme system does not infringe on the patent holder’s rights.
The final result of the search was US Patent Application No. 11/207,514 filed August 19, 2005. Titled, “Parking Space Locator,” the patent application was filed by Alan L. Browne, Osman D. Altan, and Douglas P. Rheaume. A general description of the patent application is as following: “Method for identifying available parking spaces. Receive data about a parking space from a vehicle including geographic indicator associated with the parking space. Storing the data in a database of available parking spaces. Receiving a geographic location from a parking space requestor. Searching a database for an available space. If a space is available, transmit a geographic indicator to the requestor.” A concept diagram of this patent application can be viewed in Figure 2-5.
Figure 2-5: Concept Drawing of Parking Space Locator Patent Application
Similar to the other patent applications discussed, this patent application describes components that are part of the PARKme system such as parking space sensors and a database of available parking spaces. This patent application describes finding parking spaces via a GPS-like device located within the vehicle. The GPS device would locate nearby parking spaces. The database accessed by the GPS device would charge a usage fee or require a mobile subscription. The system described by the patent is different from the PARKme system in that the PARKme system does not rely on a car’s GPS device to find available parking spaces. A PARKme system patent application would not infringe on the rights of this patent application if the application is accepted and becomes a patent.