IE 5111 Systems Engineering Group Report.docx

7/30/2019 IE 5111 Systems Engineering Group Report.docx

1/67

Running Head: IE 5111 SYSTEMS ENGINEERING I FINAL REPORT: NAVIGATORS

IE 5111 Systems Engineering I Final Report: Navigators

Alex Andrews, Belinda Befort, Emily Chen, Stephanie Cramer,Alex Martinez, Kevin Um, Meagan Young

University of MinnesotaTwin Cities


2/67

IE 5111 SYSTEMS ENGINEERING I FINAL REPORT: NAVIGATORS 2

Abstract

Increasing awareness while in the midst of driving, walking, biking, or using public

transportation is of great concern in recent years as the number of cell phone and GPS related

accidents increases annually. In this vein, the following report outlines the primary points taken

to develop a heads up display that resembles an everyday pair of glasses. Heads up displays have

been in use by the military in fighter jets as well as some high performance sports cars, however

their use has largely been segregated from the general populous. However, the idea behind them

can easily be extrapolated to everyday use in navigation. Simple overlay of directions of a users

field of view would improve efficiency of travel, as well as negate the risk of looking at a cell

phone or GPS while in transport.

In producing a concept for heads up display, titled The Navigators, a hybrid of systems

engineering concepts and the DoDAF framework was used. Therefore, an AV-1, an OV-1, an

OV-2, an OV-5, as well as several architectures and a risk plan were developed. In doing this,

the design was refined from higher-level structures such as the functional analysis and system

architecture. In this way, the design meets the requirements without harboring preexisting

notions of how the system should be constructed.

After completing the analysis, the resulting design accomplished all requirements.

However, as there are a lot of electromechanical intricacies in this project, the physical design of

subsystems are suggestions versus detailed designs. This project would have to be done in

conjunction with a design engineering team to ensure that the designs were acceptable.


3/67


Introduction

Cell phones and GPS devices, while convenient in some ways, have become a hassle in

others. Under certain modes of transportation they can increase the risk of causing an accident or

severely decreasing user concentration on his or her surrounding environment. The following

report seeks to address this problem through the development of a new hands-free system that

will allow people to navigate their way to destination without the distractions of manual input or

looking away from their route to a small graphic display.

Overview and Summary Information

When beginning a project, the project goals must be set and the assumptions and

background of the project must be established. The main stakeholders, particularly those who

have a large effect on the success of the project, must be identified. These factors are all

addressed in the Overview and Summary Information (AV-1), which gives a high-level overview

of the projects, establishes basic architecture, and is essentially the foundation of the system. The

AV-1 for the Navigators system can be found in the Appendix.

The architects of the Navigators system are Alex Andrews, Belinda Befort, Emily Chen,

Stephanie Cramer, Kevin Um, and Meagan Young. The purpose of this project is to develop an

affordable, compact, hands-free GPS device within four months at a cost not exceeding

$5,000,000. The scope was set at four months because the high-tech field moves quickly, and

since this is a modification of an existing technology, relatively little research and development

(R&D) would be needed. Thus, four months is a realistic timescale to develop and launch the

Navigators. $5,000,000 was chosen as the cost because it should cover the costs of engineers and

operators for developing, testing, manufacturing, and marketing the initial run of the product in


4/67


the short time frame required of the project. The geographic scope is to first launch the

Navigators inside the United States, due to greater demand, ease of gauging the market, and legal

ease (if the product is to be launched internationally it would require international patents.) If

the product is successful in the United States, we will launch in other countries with large

consumer bases.

The milestones for the project range from the completion of the AV-1 to the final

presentation and report, and include the development of user needs, system requirement,

functional analysis, architecture, verification and validation, and risk management plans. The

deliverable of this project is a lightweight optical device that displays GPS information while not

impairing normal eyesight functions which meets the criteria stated in the purpose. The mission

includes that this GPS device will be easily usable for bikers and pedestrians as well as drivers.

The design team envisions a glasses-like design that displays GPS information and receives

voice input.

There are several disadvantages and potential threats to the success of the Navigators

system. First, there is the possibility that the Navigators glasses may be more distracting than

current GPS models. It is assumed that, through careful design, a less distracting system can be

developed. This can be accomplished by designing an unobtrusive display, and easy-to-operate

user interface, and making it hands-free and voice operated. Many drivers must take their hands

off the wheel or stop to adjust most traditional GPS systems, and must look away from the road

to see the GPS screen. By putting the GPS display in lenses right in front of the users eyes and

making the system hands-free, both of these distractions should be solved. These features will be

refined through testing.


5/67


A second threat is that the technology may not be able to keep up with the user needs,

especially within the short timeframe of product development. However, the technology

required for the product already exists, and indeed, similar products for other applications have

been introduced, such as navigational visors for military purposes and Sonys Entertainment

Access Glasses. The main challenge in creating this product would be making it small,

unobtrusive, and weatherproof enough for bikers and pedestrians. These changes should require

minimal R&D and thus the system could be developed in four months.

A third threat would be user problems: malfunctions and ergonomic issues. With

extensive user testing and careful consideration of materials used and technological capabilities,

a product can be developed with the necessary speed and security but light and comfortable

enough to prevent ergonomic issues. The final threat would be the cost of the Navigators. By

focusing on user-friendly design and portability and using market surveys, a product will be

developed that users are willing to pay more for than a traditional GPS. By designing a smaller

system, less material will be used and costs kept low.

In designing the Navigators system, several assumptions and constraints had to be made.

First, the system is constrained to be hands-free and provide less distraction than a traditional

GPS, as discussed above. A GPS signal is assumed to be available in all places the Navigators

are used. Since the Navigators will be used by pedestrians and bicyclists as well as drivers,

another constraint is that the system must be able to withstand a range of ambient temperature

conditions, from -20 to 50 C. It also needs to be waterproof, so it can work in rain or snow.

Another constraint is that all IEEE codes and DOT codes must be followed. We want to avoid

any legal or approval issues, and following all IEEE codes ensures that the technology is

compatible with other IEEE approved technology and thus can be used more widely. Another


6/67


assumption is that the Navigators will be connected to other industries via the use of GPS

technology and information. Since the system will not draw information from privately owned

satellites or internal GPS information, the system relies on partnerships with GPS companies to

provide the coordinates and triangulation algorithms processed by its software. Last, the

Navigators must be easily expandable to other applications, such as for educational purposes

(viewing a presentation via the glasses, for example, reducing the need for large screens) or

entertainment. This constraint was added so that the market for the Navigators technology and

design could be easily expanded, and this opens the door for additional collaboration with non-

GPS companies.

Based on the assumptions behind the system and the capabilities of the Navigators, there

are several basic rules the system must follow. First, GPS satellite connectivity is required to

retrieve user locations and update real-time directions; that is based off of the assumption that

this system will be used where there are GPS satellite signals. Second, the system can be used

by a single user only. The glasses are designed for a single user, and will be customized to that

person when first used (for example, the user provides a short voice sample so that the GPS can

easily recognize the voice for voice commands.) There will also be options for the Navigators

user to add coatings to the lenses like real glasses. If more than one user uses the system, there

could be misinformation errors or ergonomic issues. This would make the system more

distracting and less easy-to-use than a traditional GPS system, violating the non-distraction

assumption. As just stated, another rule is that the system will come in a standard form, but there

will be opportunities for individual calibration for varying levels of eyesight required, and

capability for customization of glass. This allows the Navigators to be mass-produced, lowering

costs of production, but keeps customers happy by allowing them to customize their Navigators


7/67


if they desire. The device is to be sold in technology stores nationwide, because that would be

the main demographic and is similar to where GPS devices are sold. The system must also be

safe for use by licensed drivers, cautious cyclists, and pedestrians. Safety is paramount, and first

rule of designing the system is that it cannot distract or otherwise endanger its users.

After research of the utility and limitations of the Navigators system, time limitation of

the project and the technology available was found to be a concern, but the Navigators have great

potential for applications in many fields. In four months, it may be difficult to round up the

technology to develop the product with all the features that we envision. Features and to some

extent, performance, can be sacrificed for ease of use and availabilitythe minimally viable

product. We can then roll out more products with more features and greater capabilities. Even

so, it may be difficult to develop a thin, durable screen to display GPS information while still

seeming like glasses. Another finding is that one essential requirement is a small size and weight

of the system. To ensure user comfort, it is important to use lightweight materials. Average

sunglasses generally weight 2-5 ounces, so our product should be close to that range. We also

found that a major factor in the rejection of entertainment glasses technology is the bulkiness

and general unattractiveness of the system. Thus, we must create a small system that resembles

real glasses. Since we will not need to display videos or have lots of storage like entertainment

systems do, we can use smaller processors, avoiding the bulky protrusions of most similar

products. Another limitation is the update speed of the GPS. We must partner with a company

with reliable GPS information and have enough processing power to update the information

quickly enough for drivers. We have also found that when drivers do not need to turn their heads

and look away from the road to view GPS information, and use a hands free system, they are less


8/67


distracted from driving and find it more convenient to use a GPS system---thus the value

proposition of the Navigators.

The main stakeholders for this project can be classified into users, the government, the

private sector, industrial stakeholders, IT and computer companies, and future expansions of the

technology. The main users of the Navigators are pedestrians, bikers, and drivers. Pedestrians

and bikers will be using the Navigators in ambient conditions, so will need a waterproof, durable

product. They will also be concerned with the portability, visual design, and ease of use of the

system, since they will be using it in public without free hands. They also need a system that

takes sidewalks and side streets into account and has an option to avoid highways. Pedestrians

and cyclists currently have no GPS available and move slowly, so if the Navigator meets their

needs and is priced reasonably, they will purchase the product. Drivers have significantly more

choice in GPS systems and move more quickly, so speed of updating and currency of traffic and

route information is more important. Drivers, too, are looking for ease of use, and the hands-free

nature of the product may prove attractive. The government entities interested in the Navigators

include the federal government, the military, the DOT, DMV, and public transportation. The

DOT, DMV, and the federal government are all involved in the regulation of technology like the

Navigators. The military and public transportation may be interested in uses, modifications, and

large-scale implementations of the Navigators.

The private sector stakeholders include the GPS, optical, power/battery, and audio

sectors, as well as possible competitors. Since we will be relying others GPS satellites and

information, we must collaborate with GPS companies. Other GPS companies will be

competitors and thus will be affected by the Navigators. We will be collaborating with the

optical, power/battery, and audio, and IT sectors because we use these components in the


9/67


Navigators and will partner with these companies. To provide software support, updates, security

for GPS systems, especially if the Navigators expand to federal or military applications, we will

need to partner with IT, software, and computer security companies. We will also partner with

the industrial stakeholders, sellers of raw materials, manufacturers of electronics, and

automakers. (Eventually, we may combine the glasses technology with windshields, allowing

built-in GPSes in cars.) We may also expand to other applications of the glasses display. For

example, class material and powerpoints could be sent to the glasses instead of GPS information,

making the Navigator technology an educational tool. Instead of handouts or projection screens,

each person could follow the device from their own glasses. Another possible expansion of the

technology would be for entertainment. Subtitles for games, performances, or movies could be

unobtrusively be displayed on the bottom of the glasses, so that deaf viewers could see subtitles

without having to go to special subtitle viewings, and non-language speakers could understand

movies in any language. The needs of the stakeholders listed and the resultant system

requirements are detailed in the Users and User Needs section found on page 15 of this report.


10/67


High-level Operational Concept Graphic

The High-level Operational Concept Graphic (OV-1) uses generic images to convey

basic system organization concepts stakeholders involved in the system design. It is the most

general of the architecture-description products and the most flexible in format. Its main utility is

as a facilitator of human communication, and it is intended for presentation to high-level

decision makers (DoDAF, 1997, p. 4-7).

The OV-1 developed for the Navigators system is shown in Figure 1. The power button

provides a signal to the energy source, displayed here as a battery. The energy provided by the

battery to the computer chip allows for general system operations. GPS input is required for

display output on the monitor. In the Navigators, the glasses will serve as the display interface.

The information displayed on the glasses will ultimately be viewed by the user. The system

organization and subsystem mechanisms will be discussed in further detail in the following

sections.

Figure 1. High-level Operational Concept Graphic (OV-1)Navigators


11/67


High-level Operational Node Connectivity Description

The High-level Operational Node Connectivity Description, or OV-2, portrays the

relationships of nodes in the system and pertinent information exchange. (DoDAF, 1997, p. 4-

10). Relationships are represented by arrows pointing in the direction of information flow

between nodes and indicate characteristics of information, volume requirements, security

or classification level, timeliness, and requirements for information system interoperability

(DoDAF, 1997, p. 4-10). Unlike the OV-1, the OV-2 portrays external operations required to

make the system work, rather than enabling subsystems.

The OV-2 for the Navigators system consists of the following nodes: the Navigators

themselves; IT; government entities such as lawmakers, military, the Department of

Transportation, and the Department of Motor Vehicles; users/consumers; retail stores; power;

private sector companies (primarily GPS); and industrial sector companies. Each of these nodes

has a relationship with at least one other node. Some of these relationships are strictly one-way

whereas others extend both ways between nodes. The illustration of these relationships is

provided in Figure 2. The central node related to all other nodes is the Navigators device, thus it

is the most dominant with regards to OV-2 node relationships. It has, at the very least, a one-way

relationship with all other nodes. The node with the next highest number of relationships, one- or

two-way, is the government and government-related entities.

The numbered node relationships in Figure 2 are listed and detailed in a list of Need

Lines provided in Table 1 in the Appendix. The need lines are indicated by arrows on the OV-2

and point in the direction of the information or command exchange. For example, the federal and

state governments will set the laws by which the primary users of the Navigators will follow.

States have different rules regarding driving and the use of mobile devices, such as cell phones.


12/67


New legislation will most likely need to be introduced regarding the use of Navigators while

operating an automobile.

With regards to the aesthetic components of the system design, consumers (users) will

provide feedback to stores both directly and indirectly through their purchases which styles and

designs are most popular. The most popular designs will determine how many of each color or

model will be manufactured in industry.

Figure 2. High-Level Operational Node Connectivity Description (OV-2)Navigators

Industrial

Governnment GPS

Power

UsersRetailStores

IT

Navigators

1, 23, 4

5

6, 78

9

10, 11

12, 13

14, 15

16, 171

19

20

2


13/67


Command Relationships Chart

The Command Relationships Chart, or OV-4, is a visual presentation of relationships

between organizations or resources in an architecture (DoDAF, 1997, p. 4-36). The types of

relationships typically depicted in an OV-4 include command and control as well as coordination

(DoDAF, 1997, p. 4-36). Relationships such as these are displayed in the OV-4 for Navigators,

Inc. provided in Figure 3. The company is run by a CEO, who commands three central Vice

Presidents (VPs). The VPs are in charge of the three main divisions of the company: human

resources (HR) and finance, engineering, and marketing.

Human resources and finance encompass all monetary workings (i.e. accounts),

recruitment of new employees, as well as internal relations between employees and conflict. The

finance/accounting department covers paychecks, overhead and administrative costs, grants,

stocks, and investments for Navigators, Inc. The human resources department is responsible for

the recruitment and retention of employees, which involves outreach to universities for college

interns, as well as training programs for healthy employee relationships within the company.

They are involved in the storing and filing of employee paperwork, employee training, ensuring

the companys compliance with labor laws, researching competitive salaries, and employee

discipline.

Engineering breaks into two main departments: research and development (R&D) as well

as technical staff across the fields of electrical, mechanical, computer, and systems engineering.

The R&D department is responsible for researching patents, products, and technology currently

available in the market and academia, as well as researching and developing new technology to

be used exclusively by Navigators, Inc. Technological innovation is a driving force behind the

Navigators, and new applications of this technology will be expanded to other industries in


14/67


addition to travel in the near future. In the design department of the engineering branch of

Navigators, Inc., teams of engineers rely on good communication between disciplines to design a

final product with interconnected subsystems that operate smoothly.

The third and final division, marketing, develops the aesthetic design and advertising for

the final product developed by Navigators, Inc. Naturally the aesthetic design is guided by the

functional design developed by the engineering teams, but consumer tastes and needs are crucial

for the development and sale of the Navigators product. The marketing team provides input

regarding the users and user needs from the point of the consumer to ensure the product will be

successful on the market.

Figure 3. Command Relationships Chart (OV-4)Navigators, Inc.

CEO

VP HR Finance VP En ineerin VP Marketin

Accounts

Recruitment

Internal

Relations

Research &

Develo mentElectrical

En ineerin

Mechanical

En ineerin

Computer

En ineerin

Systems

En ineerin

Desi n

Advertisin


15/67


Users and User Needs

User needs are necessary to develop the basic requirements of the various project stakeholders

provided in the AV-1. This section will discuss the development and justification of the user

needs for Navigators, which will be used to develop the more detailed system requirements in the

following section. The user needs for the Navigators were developed for the primary users,

mainly pedestrians, bikers, and drivers. Secondary stakeholders include government entities such

as lawmakers, military, the Department of Transportation, and the Department of Motor

Vehicles, as well as GPS companies and the industrial sector companies that will be

manufacturing the systems components.

The primary user needs can be divided into a number of general subcategories somewhat

similar to those of the system requirements. These subcategories include physical characteristics,

technical specifications, and economic expectations. Physical characteristics are defined as those

having to do with the physical appearance or properties of the final product. Technical

specifications include anything related to the interior technology that allows the system to

function. Economic expectations encompass cost and retail standards following the manufacture

and distribution of the final product. The subcategories of primary user needs will be discussed

in greater detail below.

The physical user needs of the Navigators include the following:

LightweightDurable

Waterproof

Portable

Aesthetics

AdjustableSun protection

No lotus effect

Scratch resistant

Minimal glare

MaintenanceCustomization

Ease of use

Hands-free


16/67


The needs andproperties listed here should not interfere with the users comfort or ability to use

the device. Comfort is affected by the weight, size, adjustability, sun protection, and glare. The

longevity of the product will be dictated by the durability of the materials used in its

manufacturing, overall dimensions (portability), scratch resistivity of the display surface, and

waterproofing (for pedestrians in wet weather conditions). Aesthetics are entirely dependent on

user preference but essential for product marketing.

Technical specifications, those related to the internal workings of the Navigators system,

include the following user needs:

Frequently updated

No technological lag

Warning for nearby vehicles

Language independent

Computer memory

Zoom function

Security levels

Brightness settings

Day/night settings

Resolution

Settings for specific users

Customization

Ease of use

Hands-free

The technical needs of the primary users include technological speed, information accuracy,

information security, and program functions. Technological speed includes technological lag and

computer memory. Information accuracy is provided by frequent updates to maps and directions.

Security is necessary to protect information as well as access to various levels of detail (e.g.

military bases). Program functions include warnings for nearby vehicles, language independence

for multilingual nations and/or the expansion of product distribution to the global market, zoom,

brightness, day/night, and display resolution. These needs should be implemented and up-to-date

with the most recent technological and security standards.


17/67


One may note the inclusion of customization, ease of use, and hands-free in both

physical and technological user needs. The need for customization applies to both as the user

may request different styles of frames or display surfaces, as well as the ability to customize their

device to store different destinations or personal information. Moreover, the potential for

subsequent updates to the Navigators device may include applications related to audio/visual

entertainment or education. Likewise, ease of use is required in both physical and technical

designs of the system so the user will undergo minimal or no training prior to using the

Navigators device. Similarly, the need for a hands-free GPS device overlaps with physical

requirements for data input mechanisms as well as the technical programming to receive the data

transmitted to the device.

Economic expectations, the third group of primary user needs, includes the following:

Quality

Affordable

Reliable

Convenient

Economical

The economic and retail standards deal with the relationship between the user, device, and its

sale in retail stores nationwide. In short, this relationship and group of needs can be considered

the driving force behind successful marketing of the product once it reaches widescale

distribution. A more detailed breakdown of marketing needs and requirements will be

determined by the marketing team at Navigators, Inc.

Secondary users, such as government entities and industrial sector companies, have a

different set of user needs than those of the primary users discussed above. Government entities

will be largely interested in security of data and its transmission, the accuracy of provided

information, as well as civilian safety. Lawmakers will enforce the passing of regulations to


18/67


ensure user attention to the road is not inhibited by the Navigators system, similar to cell phones

or other electronic devices. Government entities in this context refer to the United States

government. These needs may have to be changed for other countries should the Navigators

system be distributed globally. Driving laws and road regulations vary country-by-country, so

the GPS program integration with the Navigators system must be considered and modified

accordingly.

GPS companies constitute another faction of the secondary stakeholders. Since the first

generation Navigators will be used primarily for navigational purposes, GPS companies will

require accessibility to data, satellite usage, and tracking information in order to provide the

appropriate information to the Navigators to display on the user interface. Should future

generations of the Navigators expand their scope to include audio/visual entertainment,

education, or other applications, the user needs will be modified to reflect this expansion in

application capabilities.

The industrial sector will require materials information from users and Navigators

designers for production and assembly purposes. Material selection will be important to achieve

the primary user need of durability, glare and scratch resistance, and waterproofing, among

others. Of the economic expectations of primary users, affordability and quality will also be of

importance to industrial sector stakeholders as different materials will offer different qualities of

service (e.g. a material with a greater hardness and thus resistance to scratches). These are just

some of the needs considerations of secondary stakeholders in the development of Navigators

devices. The user needs presented here will be used to develop the general and detailed

requirements of the system, which will be presented and discussed in the next section of this

report.


19/67


System Requirements

A requirement is something that the product must do or a quality that the product must

have. A requirement exists either because the type of product demands certain functions or

qualities, or the client wants that requirement to be part of the delive red product. (Monson,

2012a, p. 1). System requirements are essential for the success of the project and take up

approximately 8-14% of the overall project cost (Monson, 2012a, p. 1). Moreover, system

requirements help to determine the project scope. For example, they help define what is going to

be developed or who will be responsible for which task. They reveal where further research is

necessary during the development phases of a project. System requirements are a driving force in

a project that moves it toward a final solution, rather than reversing the process (Monson, 2012a,

p. 1).

The main reason for spending much time on system requirements is to outline details to

understand the finer points of the system and how the subsystems will interact. In the end this

will save the project time and money. This allows for example a higher efficiency through

communication, less time spent on revising product or service requirements during or after

implementation and fewer contract changes with external vendors. With good requirements

better product and service quality and performance accountability can be achieved (Monson,

2012a,

p. 1).

System Requirements can be divided into eight different types: functional, technical,

usability, operational, security, physical, support and training requirements (Monson, 2012b,

slide 61-63). Many system requirements also have a super- or sub-requirement. Super-

requirements are required to be in place prior to the implementation of the given requirement.

Similarly, sub-requirements can be included following the implementation of the given


20/67


requirement. In the following pages, each type of requirement is defined and then it is applied to

the Navigators system. A more detailed list of all system requirements, as well as any super- or

sub-requirements, is provided in Table 2 in the Appendix. In the following will be a discussion

of their contents.

Functional Requirements

The functional requirements reflect what the product or service needs to do through

implementation of action requirements and workflow steps (Monson, 2012b, slide 61). Simply

put, it is what the Navigators are expected to do for the primary users (consumers).

In considering the functional requirements for the Navigators system, the device shall

display graphic overlay navigation and up-to-date information. This is extremely important for

newly constructed roads or road changes so the user is still able to use the Navigators with only

minimal updates required. Moreover, the system shall display directions over area viewed by

users, so that if the user is turning his or her head the navigation information will still be

provided in the correct orientation. This will require the implementation of a gyroscope.

Given the actual maps and directional information is correct, the Navigators must also

indicate the users current location by calculating the route to his or her intended destination.

Route calculation requires total travel time and amount of miles to the destination. Furthermore

the system shall adjust travel time to velocity of user, so the time and miles left to the destination

will be updated frequently so the user will be updated about his or her travelling status.

Sub-requirements of the aforementioned requirements are that the system shall provide

the option for the fastest route in respect to time, the shortest route in respect to distance and

most fuel efficient route. Depending on the situation or user, there might be a different purpose


21/67


for getting to a destination requiring shortest or longest time or distance. These options will be

provided for the user, as well as the ability to see where traffic may be congested along a given

route. For ease of use the system shall maintain the option to save 30 destinations and maintain a

record of the last 20 destinations. Because of this function, the user will save time entering his or

her destination. Each user will have his or her personal destinations they frequent more than

others.

Furthermore, the Navigators shall automatically turn on when opening the temple arms of

the glasses and automatically shut down when the user the user closes the temple arms of the

glasses. Thus the user would not have to bother with giving special input for turning on or

shutting down the system and it would save time in actually using the glasses. The last functional

requirement for the Navigators system will be that the system shall charge its own battery.

Technical Requirements

The technical requirements consider the conformance to standards and system type

(Monson, 2012b, slide 61). Under these requirements, the Navigators shall use a TI M3 Context

processor and a TI C6000 Digital Signal Processor for graphics realization and the system shall

conform to IEEE standards. Moreover, the system shall use at minimum a 2000 mAh battery for

providing the power necessary for processing and displaying information. For the ability to make

the system available for every person, the system shall provide software which is compatible

with the following: Windows XP or later for Microsoft operating systems, OSX 10.6 or later for

Macintosh operating systems, and the most recent version of Linux. In addition the system shall

provide interface software compatible with Macintosh iOS and Google Android mobile

operating systems.


22/67


Usability Requirements

The usability requirements describe how the functional requirements should be executed.

Usability includes the following characteristics: user-friendly, graphic user interface, reliability,

speed, accuracy and number of steps to complete the task (Monson, 2012b, slide 62).

Applying the usability requirements to the Navigator system will show that the system

shall be language independent. For example, there are many Spanish speaking people living in

the United States who do not have English as a mother tongue. There will be an option to change

the graphic information display (as well as information input) to Spanish so it is easier for these

users to understand the information, especially because it is mostly technical vocabulary. The

technical vocabulary may make it difficult for people to understand if English is not their native

language. Moreover for future potential expansions to other countries the language function is

already included.

In addition to language independence, the Navigators system shall indicate status. This

means that the system will show if the device is on, off, standby, or maintenance. Another

usability requirement is the system shall provide fast tracking and suggestions for the user input.

The user can save time so he or she does not have to remember the exact address because the

system will start providing suggestions because of fast tracking (similar to internet searches). An

important fact in the sense of user security is that the system shall not distract the user from their

responsibility to pay attention to traffic. Therefore the system shall not provide too much

information at once and the information should be shown for an amount of time that the user

does not have to rush to understand it. In addition to traffic, the displayed information shall not

hide important signals or signs on the street from the user. The Navigators system shall allow

the user to adjust quantity and type of information displayed on the screen. Some users might


23/67


like to see more information at once, such as driving speed, average speed, time and miles left

until reaching the destination, and speed limit. Other users might be distracted by too much

information and their mental workload will rise, so they might prefer to reduce the amount of

information displayed on their system. With regards to the physical architecture of the system, it

shall be user adjustable in the way of adjusting the bridge and the length and the angle of the

temple arms, which will make it easier for the user to read the displayed information.

For the subcategory graphic user interface there are several system requirements that

should be taken into account. For example, the system shall provide visual navigation

information. The system must provide adequate font size to be usable by persons with limited

visual acuity. Because of this the system is not limited to individuals with perfect vision and

opens up a greater customer base to people with limited visual acuity who may have difficulty

using an internal navigation system in a car or other GPS device. Furthermore, to handle the

navigation information more easily the system shall display the name of upcoming intersections

and exits which should be taken. That will also show redundancy with the graphic information

and so it reduces the mental load of the user.

The next subcategory, reliability, will include the system requirements that the system

shall experience no technical lag. The system must be 99.99% in line with actual user movement;

otherwise the user will be distracted by the lag of the graphic display and not able to navigate

safely. The subcategory speed will as well be considered for the Navigator system. One system

requirement which will be in this subcategory is that the system shall provide navigation

information five seconds after destination input from the user. Because of that a fast output will

be provided and the user will get directions shortly after his/her input. A short time to


24/67


information display following input will allow the user to start driving, walking or cycling and

follow the navigation information which will show up shortly after beginning travel.

With respect to time of use, system shall be usable for 30 continuous hours of average use

before charging the battery. In that amount of time the driver should be at least able to complete

four long distance trips or 15 trips of two hours each before recharging the system. Additionally,

the Navigators system shall not average more than five minutes to install or upgrade Navigator

software on the users personal computer/laptop, and they shall not average more than ten

minutes to upgrade the embedded Navigator software itself. Navigators are a non-essential

device for daily life, so the user shall not spend much additional time updating the system

compared to its actual time in use.

A final subcategory on which should be mentioned is the subcategory accuracy which

will include the system requirements that the system shall measure distance to three meters

accuracy. Moreover, the system shall display distance to the user in the largest unit denomination

greater than or equal to one. For example, if the distance to a destination is half a mile, the total

distance will be provided in feet, rather than 0.5 miles. Additionally, the system shall use

accurate industry-standard geographic information. The last requirement is especially important

in the sense of new streets or rearranging the route of the street or size of the street. The graphic

overlay of navigation information will not only provide directions on the road but they will also

take into account the number of lanes and adjust arrows accordingly.

Operational Requirements

The operational requirements are a subcategory of the system requirements that describe

the environment around the use of the presented system (Monson, 2012b, slide 62). Operational


25/67


requirements for the Navigator system first include that the system shall be light intensity

adjustable. This is extremely important in the case of bright sunlight or darkness that the user is

still able to see the displayed navigation information and the surrounding signs, signals and

traffic. According to the different climate areas in the United States and with that the different

temperature levels the system shall tolerate temperatures between -50 to 55 degrees Celsius

(USA Today, 2011a & USA Today, 2011b). This will be even more important when the system

will be expanded for people all over the world. The same reason as mentioned before about the

different climate areas will come up with the next system requirement that the system shall

withstand 100% humidity. Additionally, dependant on the humidity and the surrounding weather

the system shall not cloud the vision of the user. This point will be very important for people

going from cold areas to warm area, such as going from outside on cold winter day to inside a

warm car.

Security Requirements

The security requirements will include confidentiality, accessibility and legal

considerations about the considered system (Monson, 2012b, slide 62). Overall the system shall

not replace manual driving skills. The driver still has to consider surrounding traffic and signs

and streets which might be different to the information displayed in the glasses. In the sense of

accessibility the Navigators system shall not have sharp edging that someone would be able to

cut him- or herself while using the Navigators. Moreover, the system shall not pinch the finger of

the user when opening the temple arms of the glasses. Additionally, the Navigators lenses shall

be made of safety glasses that in the case of an accident the glasses will not cut the face of the


26/67


user or damage their eyes. In the case of the system accidentally being dropped on the ground,

the display interface will not be made of material that can easily shatter.

The system shall not cause health problems by people using the Navigation. Material use

will include safe, approved plastics and metals for proximity to the human face. Legal

considerations in the security requirements subcategory will include that system conforms to IT,

federal and military security standards. Furthermore, the system shall not be used by any driver

under 18 years of age because there are laws about usage of hands free devices in some states

which will forbid the use for people under the age of 18 (Minnesota Department of Public Safety

Driver and Vehicle Services Division, 2012). Therefore the presented requirement is to prevent

the user from breaking state and federal driving laws. In relation to the previous requirement (but

not entirely regulated by the law), the system shall not be recommended for use by pedestrian or

cyclist under 12 years of age. This, again, is for user safety and compliance with transportation

laws.

For confidentiality the Navigator system shall be encrypted to security standards.

Personal destinations should be not accessible by other users (or even the government with

certain privacy laws). Furthermore, people should not be able to hack into the Navigator system

and be able to change to displayed information to cause an accident or crime.

Physical Requirements

Another subcategory of the system requirements are the physical requirements, which

include equipment size limitations, portability, weight limitations, materials, durability and

company brand requirements (Monson, 2012b, slide 62). With regards to size limitations, the

system shall not exceed 7.5 x 3.8 x 3.3 inches when stored in a spectacle case and the system


27/67


shall not exceed 7.5 x 7.5 x 3.8 inches when in use. With these size limitations, the Navigators

will not exceed the size of sunglasses by much. It will be a convenient and familiar size for

primary users. In addition to the size limitation is a weight limitation. The system shall not

exceed seven ounces, which was determined to be appropriate for a glasses system to avoid

irritation of the neck or face.

Moving on to the category materials-durability, the frame shall have a chrome finish.

Moreover, the Navigators shall be sold with a storage case that protects the device against

crushing, torque and scratches. Damage to the glasses could impede the view of the user and

with that distract the user from the surrounding traffic. Repairs to the device could potentially be

expensive. The glass display surface itself shall be transparent and have sun protection.

Transparency will allow a user to use the Navigators at night. The sun protection is important for

drivers of convertible cars who would probably not use the Navigators without sun protection

because in a convertible there is a high risk of sun burns. This fact will also be important for

bicycle riders and pedestrians using the Navigators. In very humid weather conditions or in the

case of dirt clinging to the glasses, the system shall provide glasses with no lotus effect. This

implementation will allow the dirt or water to run down the glasses automatically so no cleaning

is required during use. This, again, will minimize distractions for the user.

Considering the design of the glasses, the Navigators shall be released in a modern design

and in different colors. Additionally the system shall provide a storage case in at least 10

different colors. These requirements reflect the customization and the user might feel more

related or attached to the glasses when choosing their own design. Furthermore the Navigators

surface shall not exceed 38 degrees Celsius so that the user will not be burned by the device. For


28/67


long distance travel or extensive use of the Navigators, the system shall provide a place in the

storage case for an alternative battery.

Support Requirements

Support requirements include maintainability and service level requirements (Monson,

2012b, slide 63). According to support requirements, the system shall operate without

maintenance for a period of at least one year. Moreover, the system shall be repairable because

of higher quality and software and not be a one-time technical device. The Navigators shall be

updateable. Because of this the newest software updates will be available for the user of the

Navigators. Additionally, the system shall have a maintenance panel with which the repair or

maintenance can be done. The system will indicate which the part of the Navigators which needs

repair or maintenance.

Similar to the previously mentioned requirement is the requirement that the system shall

internally notify technical support representatives of malfunctions for immediate repair.

Furthermore, the system shall include a care manual with which the user will not clean or

maintain the Navigators incorrectly and with this reduce repairs and damages to the system.

Since the Navigators are easy to use and are used (at this point) only during travel, the system

shall only require in-depth cleaning and repair after six months. If a repair is necessary to the

Navigators there should be a service representative available 24 hours per day and the system

shall be repaired within five business days of service call.

Training Requirements

The training requirements will include the details about training the trainer, training

specified number of business or technical users and the number of hours or days are used for


29/67


training (Monson, 2012b, slide 63). With regards to the Navigators system, no prior training shall

be required on part of the user, but the system shall provide access to tutorials for first-time

users. Because of this users with more experience with technical devices will be able to use the

Navigators with intuitive ease, and users with less experience with technical devices can use the

tutorials prior to their first use and become familiar with the device.


30/67


Functional Analysis

Functional analysis is one of the most basic tools in systems engineering, and is used

extensively to develop the system architecture, where the components of the system can be

further defined. This simple tool allows engineers and designers to look beyond what is currently

available into the realm of what is possible. Frequently, engineering teams will look to the

current market to derive products, and use preconceived notions of acceptable to do design

work. However, this is frequently insufficient, especially in high tech industries where

innovation is key. When systems engineers begin to design new products, a functional analysis is

done to truly understand what is needed from the product and what is not. This helps take the

potential product out of the physical world, and allow the engineer to forgo any design that has

previously been developed. It also allows the engineer to become more in tune with how and

where the product will be used, so as to better design the physical components later in the

process. Thus, functional analysis is especially important during the initial, preliminary stages of

design, when the item to be produced is still a somewhat vague concept, and can be molded

throughout the process to end at the most suitable and innovative design.

For the product in question, the functional analysis was just as any other would be. It was

a walkthrough of what the product needed to do, and what it did not need to do. The functional

analysis in any electromechanical system is slightly more complex, simply because of the

complexity of the end result. Shown below are the functions deemed appropriate for this product.


31/67


What does this system need to do?

Switch on/off Regulate Power Supply to Elements Recharge Monitor Power Supply Level Record System Failure Details Supply Software Supply GIS Database Record User Preferences Record Destinations

Prioritize Functions

Render Display Handle System Failures Detect Display Orientation Detect GPS Location Connect to Wireless Device Display Directions Report System Failure Query User Preferences Listen for Voice Commands

At this point, it is useful to define the states this system must be in, as this will help

further define the tasks that need to be accomplished to define this system as a success. In this

system, the states that are possible are as follows

Navigation Off Computer Control

Recharging Pre-Shutoff.

Simply from these states, a lot can be gleaned about the needed system. When in the

Navigation state, the system is operating at nearly full capacity. The system is displaying

directions overlaid on the environment to the user, and it is continually updating position and

direction to provide accurate directions. It is also consuming power, communicating to a GPS

satellite, and can communicate to a Bluetooth device such as a cell phone to acquire directions.

In addition, this state is the only one in which the system communicates any problems

encountered to the user, so the glasses need to be continuously monitoring for software faults and


32/67


firmware issues to display. This state is the primary state in which the user will interact with the

system, thus nearly every function needs to be operating during this time. The second state is the

Off state. This state is fairly self-explanatory, and is the state in which the system is not in use.

Note that there is no standby state, as this system is unlikely to need one. Since the system is

only on when the temple bars are open, they are likely to be on someones face at that point.

When they are shut, the glasses cannot be in use, and can simply be off.

The next state available is Computer Control. This state is important, as the glasses

themselves will not have any tactile control on themselves. Thus, any updates or troubleshooting

that is needed shall be done on another device. When in this state, the system will not be

displaying anything, and thus will not be available for use. However, the processor and data

storage components still need to be operational in order for the computer resolve any issues.

These issues need not be flaws in the system; they may be standard upkeep such as updating

firmware, updating the GIS data, or setting Bluetooth preferences. Conversely, they indeed may

be issues in the software, problems connecting to GPS satellites, or data storage problems. In this

state, the system need not draw power from its own battery, as the processor can simply draw

power from the device it is connected to. The next state listed is very similar to Computer

Control; Recharging. In the Recharging state, the processor is not available, nor the display.

There is no user interaction, and the only part of the system functioning is the battery. Thus, it is

almost the inverse of the Computer Control state.

The final state that logically is defined is Pre-Shutoff. This state is complex, as it is a

state defined between two states: Navigation and Off. Between these two, all data input into the

system during operation needs to be stored for use the next time the system is used. This data can

range from user preferences, to locations navigated to, to preferring to avoid highways in


33/67


navigation. In order to accomplish this, the glasses need to stay active long enough after closing

the temple bars to access the data storage, save data, and then power down.

From the list of necessary functions, a map of how all the functions interact can be

developed, as shown on page 65 of the Appendix. Initially disregarding the coloring of the

diagram, this is a simple map of how the functions themselves need to communicate. This will

useful as it helps drill down and split up the system into independent subsystems that can be

further refined by physical design. This map can also be used to break down the system into

software components. These hardware and software definitions are two separate decompositions,

and will be referred to as the system architecture and software architecture, respectively.

The software architecture becomes clear from the functional analysis, although it is not

the focus of this design process. It is highly likely that the way the processor and data storage

hardware is designed and built by suppliers will define how the software functions with it. In

addition, this system would likely not have proprietary software initially, and this portion of the

end result would be outsourced to a reliable software company. This would lend the highest

likelihood of producing a reliable operating system to ensure success. The choice was made to

draw the borders of the box of the system to not include the programming aspect.

The system architecture, however, is almost fully realizable straight from the functional

analysis. Again referring to the diagram on page 65 of the Appendix , the systems processes start

in the bottom left corner. Supply power is obviously the first thing done, which is followed by

regulating the power supply. This would be necessary as the different components of the system,

i.e. the display, the processor, the antennae, ect., would likely all require different voltages to

operate. This is the first example of the system architecture influencing the physical design

directly.


34/67


Following the power components, the firmware starts. This is the first function carried out by the

processor, and will need to occur first in order to awake the other parts of the processor, and to

ensure the processor is in proper working order initially. At this point, the system executes

processes. This is a blanket term used intentionally to create loops. This may mean a multitude of

processes but since the brain of the processorcarries them all out, little attention will be given

to them individually. From this point, the first thing done would be the detection of wireless

device input, as the wireless device can be used to indicate desired address. From this point, the

flow goes to analyze input streams, which is another blanket term used to create a loop of

processes. This node will stand for the analysis of all inputs, both from antennae and the user.

The processor then updates the parameters, and computes the process outputs. This essentially

means that it updates the processor and creates new inputs for the processor to take into account.

The processor must then prioritize its processes. This is a dependency on the likelihood

of using a single core processor able of doing one thing at a time. This constraint is imposed

under the assumption that a single core processor will be smaller, and thus easier to allocate

space for on a system as small as a pair of eyeglasses. This also has the added benefit of likely

producing less heat, which would make the user much more comfortable. From this point, the

flow goes back to the execution of processes, which completes one loop. The second loop likely

to be made is the detection of the GPS signal, as this is the primary purpose of the system. This

would require triangulation of the signal by the satellite, as well as the transfer of information to

and from the GPS antenna. These processes were all encapsulated in one node, as this is one

single process that needs to be completed.

The next logical process to be completed is the computation of an optimal route. This

would immediately begin following the acquisition of a GPS signal and a location to navigate to.


35/67


This should be a relatively short process, and the computational power should be minimal. This

process will be influenced by preselected preferences of the user, such as the avoidance of

highways. This would then go into the computation of process outputs, and prioritized to be sent

back to the execution node.

At this point, there are three more nodes in the loop. All of these are processes that would

be happening in tandem, although not literally. As mentioned before, the processor would likely

only handle one process at a time, so the processor would have to work with its internal clock to

ensure the following functions are completed once every few milliseconds. The first function is

the detection of the display orientation. This would allow the glasses themselves to alter the

display based on the direction of the head of the user. This would be particularly useful when the

user looked up or to the side while moving forward.

The next function that happens periodically in the loop is the detection of vocal input.

The monitoring of this every few milliseconds is the most effective way of processor allocation,

as even a large delay (in milliseconds) of the detection of a command is highly unlikely to affect

the end result, or the reaction of the system. When vocal input is detected, this node is the

priority in the entire loop, and until vocal input is no longer detected, will be the only thing done

in the loop. After this input is ended, the input is analyzed and input back into the execution

phase of the processing. The last periodic function that occurs is the monitoring of the available

power. This is necessary to determine the life left in the battery, as with most electronics today.

As the rate of change in the charge left in the battery is unlikely to be high, this process can be

monitored less often than all others in the loop and still be effective.

When the system recognizes that it is in distress, it can then go to the handling of system

failure. This node is followed by reporting the system failure to the user, which has two outputs.


36/67


This failure is recorded by the system, such that it can be addressed, and it also directs to the

rendering of graphic output. This process then flows to the displaying of the information on the

lenses. The rendering and displaying of the graphic output are not limited to system failures of

course, and are connected to the computation of process outputs, as can be seen in the diagram.

The final few nodes in the map are solely when the system is connected to a computer.

Starting from the top left of the map, the system needs to first allow itself to be controlled by an

external device. This node is then connected to three nodes suboridinate to it, which can occur in

any sequence. The first is trouble-shooting issues, which is where the solution is to the problems

that occur when in operation. While in this node, the user interacts with the computer to gain

more insight into the problem, see the best way to fix it, and possibly connect to the Internet to

let the problem be resolved by others. Another node the needs a computer is the updating of the

firmware. This is required as things become newer, faster, and better than before. The third and

final node in this system is the updating of the GIS system. This is necessary every so often so as

to keep up to date on the newest construction of roads, and to ensure that the directions to be

offered.

All of the processes relating to the computer, as well as the processes in the execution of

the normal software of the system need to access a save function, indicated by the store function

node. In the final stages of this systems operation, the power is cut to all functions. This is the

end of the map, as after this node is passed, there is no more power to function.


37/67


OV-5


38/67


System Architecture

From the preceding analysis, there are a number of subsystems that these functions can be

decomposed into. These subsystems help design the product, as their further definition will help

produce requirements that the components of the subsystems will need to address. After

considering these functions, the following subsystems were deemed appropriate

Power Control Subsystem Wireless Subsystem User Input Subsystem

Processor Subsystem Display Subsystem Maintenance Subsystem

These subsystems also communicate in a specific way that can be mapped out as shown in Figure

4. The system architecture is helpful not only in realization of the inner workings of the product,

but also the inner workings of the product design process. Through this architecture, the project

may be divided among several teams, and the communication lines between nodes in the map

indicate essential communications that need to take place between functional development teams

in order to ensure that the system will operate as intended.

Figure 4. Navigators System Architecture


39/67


Physical Architecture and Its Verification and Validation (V&V)

The Navigators: GPS Glasses System, herein after referred to as the device, shall be

implemented with hardware and software, along with accompanying advanced technologies.

This physical implementation is divided into separate subsystems to be designed, in order to

obtain the benefits of modularity and compact design. The subsystems are Power Control,

Processor, Wireless Communication, User Input, and Display. After the design is complete,

verification and validation (V&V) tests are conducted to ensure proper and consistent operation

of each component in each subsystem.

Power Control System

The purpose of the power control system is to provide a stable and appropriate supply of

power to the device. The implementation is comprised of a battery storage device and a voltage

regulator and control system. The five volt battery will provide the required potential to the

devices digital systems, and will provide the appropriate power rating, high enough to support

the power intensive applications on the device, most notably the display light source and

projection. Other power intensive applications include wireless broadcast antennas for Bluetooth

and GPS. The particular battery technology will also adhere to size and safety constraints of the

device. The particular requirements can be found in the system requirements document; however

it suffices to mention here that the battery size will be hidden, with its weight indistinguishable

from the weight of the device. The safety considerations include the chemical potential and

temperature effects as potential health hazards to the user. Design considerations such as the

battery encasing and limits on power draw are design solutions to these requirements.


40/67


A mechanical switch shall be located on the hinges of the device, completing an electrical

circuit when the glasses are opened and disconnecting when the hinges of the device are closed.

The switch provides a direct means of powering off the device. This can be accomplished by a

number of methods, a couple of which are mentioned here. The switch in Figure 5 shows an

implementation that fully disconnects power to the device. In other words, the mechanical switch

fully determines power to the device. In an alternative implementation, the switch may instead

provide a status signal to the power control system. Based on the status signal, the control system

can power the device in a variety of low power configurations. This decision is left to further

consideration in collaboration with the design engineering team.

A voltage regulator is the interface between the battery and the devices components

requiring electrical power. The voltage regulator will provide the means for a stable power

supply by regulating changes in the output due to a change in load current or a change in input

supply voltage from the battery and will provide a constant reliable source for the device,

limiting noise and variation in the supply characteristics. Additional control circuitry will power

different components of the system at different amounts in response to the real time power

demands for energy efficiency. The control circuitry will be a simple passive network. A further

means of protection is the addition of fuses between the regulator and the various device

components receiving electrical power. This will prevent overcurrent and severe device

destruction and user harm.


41/67


Figure 5. Power Control Subsystem system schematic.

The verification and validation of the Power Control Subsystem is accomplished with a

number of electrical and mechanical tests conducted by the systems engineering team. The

natures of the tests are component based and functional-system based. The components, systems,

and tests can be seen in Figure 6. The test plan shows that each component will be tested on its

individual characteristics, followed by system tests for more complicated functions. Finally, the

entire subsystem is tested before being integrated into the device.

The power control subsystem provides the electrical supply for the device, but is also a

hazard source for the user. The verification and validation tests must adhere to heavy safety

standards, and the risk analysis must determine the acceptable range of results for the V&V tests

for this system.


42/67


1.0 Power Control Subsystem

Component Verification Test

Micro USB connecting to battery Electrical Test

Battery Pack

Inspection (Size), Current Draw Test, Max

Stress Test (Temperature and Durability)

Switch

Contact Test (Electricity), Life Cycle Testing,Accelerated Fatigue testing of spring loadingmechanism

Voltage Regulator Electrical Output Test

Voltage Regulator to Battery Electrical and Logic Tests

Waterproof Seal Submerge to 20m and check for leakage.

1.0 Power Control SubsystemVerification

Inspection, Test current draw, Test current atopen and closed switch positions, Test

durability, Test regulator when one or morecomponents changes voltage requirements.

Figure 6. Verification and Validation Tests for the Power Control Subsystem.

Processor System

The purpose of the processor system is to compute and implement functions and

algorithms central to operation of the device. This system also serves as the primary interface

between the other subsystems of the device. It is therefore apparent that the processor subsystem

implements several diverse functions using its computational blocks. The nature of the specific

microprocessor(s) and interface chips are left to the design engineering team. Here, the required

functions are described relative to their importance to the subsystems required characteristics.

The processor subsystem is composed of a microprocessor, a digital signal processor

(DSP), data storage devices, and power and data buses. The standard software of the device is

included in the processor subsystem as a fundamental component for implementing the various

functions. The buses and connections are illustrated in Figure 7. In general, the chips are

connected to the power supply, and each processor performs a function for each subsystem.


43/67


Figure 7. Processor Subsystem system schematic.

The Wireless Communication sends information to the processor from the devices

antennas. The data may need to be decrypted and will need to be processed to useful information

for the other subsystems such as maintenance updates or display information. The User Input

Subsystem sends raw data from the user from a microphone as analog data, and also from a

micro USB port in the form of digital data. The processor must perform analog to digital

conversion for sound information, to be sent to the DSP. Data from the serial bus should be able

to be stored and accessed in memory by any other function of the processor subsystem. The

digital signal processor handles sound and graphics intensive applications such as producing

specialized graphics or rendering the display. The DSP obtains information from the processor,

and directly outputs to the user output components, primarily the projection display.


44/67


2.0 Processor Subsystem


Processor

Inspection, Memory tests, Timing Tests,Stress Tests, Power Comsumption tests,Check for voltage spikes,

Digital Signal Processor Set up test circuit, test outputs.

Processor to DSP Electrical and Logic Tests

Processor to Microphone Electrical and Logic Tests, Sample tests

Processor to Memory Electrical and Logic Tests

Processor to Wireless Subsystem Electrical and Logic Tests

Processor to Micro USB/Computer Electrical tests and trial data transfers.

Processor to Power Control Electrical test for maximum efficiency

Software Unit Test

2.1 - Software Maintenance


Warning MessagesInduced critical state, inspection of outputfrom Processor

Power Supply ShutdownInduced critical state, inspection of outputfrom Processor

Updates to GPS software

Load initial software, check that processor

knows of update

Bluetooth UpdatesLoad initial software, check that processorknows of update

Firmware UpdatesLoad initial software, check that processorknows of update

2.1 Maintenance SubsystemVerification

Software download test, check for downloadsuccessful

2.0 Processor Subsystem Verification

Initial software download, render a display,access all memory channels, obtain GPSdirection set, access power control system,Voice control test

Figure 8. Verification and Validation tests for the Processor Subsystem.


45/67


The software is composed of algorithms for performing the mentioned functions. The

specific implementation of these algorithms and programs is highly dependent on the design

constraints and are thus left to the design engineering team. It suffices to say that the software

shall accomplish with the processor subsystem hardware all the functions described here.

The processor subsystem requires much more technical specification and consequently,

much more technical V&V testing. Such tests for each component can be found in Figure 8. This

computerized system can be tested by modeling the environment the processor will embed.

Much of the tests can be automated to test a breadth of test cases and can be repeated for

redundancy checks.

Wireless Communication System

The purpose of the wireless communication system is to provide access to Bluetooth and

GPS technologies for device communication. The physical architecture incorporates an antenna

transceiver system for both technologies. The inputs and outputs to the system are power and

data. The power is supplied by the power control system, and it should be noted that the higher

power requirements for this system indicate the need for risk safety analysis. The temperature

and radiation are factors for potential hazardous to the user. The raw data demodulated by the

system is sent to the processor system via data buses for computation and use by the device. The

specifications of the transceiver systems, as well as the specifications for the power and data

buses are highly dependent on the design implementation of the processor and power systems,

and are thus left to the design engineering group.

The validation and verification of the wireless communication system is composed of

tests on the individual antenna transceiver systems, data and power buses, and on the entire


46/67


wireless subsystem as a whole. The test plan can be seen in Figure 10. As with any other system,

integration tests are conducted to ensure correct operation of a subsystem in its supersystem. For

V&V, the components must be tested in a modeled environment independent from the device

itself. For example, testing a component such as the Bluetooth transceiver system will require the

creation of an ideal functioning environment modeling the glasses and environment. Such an

environment will be composed of a known clean power signal, data buses to a processor, and

clean wireless signals. Clearly, test cases can be varied here, and will be done so for breadth in

the V&V test plan. Redundancy or consistency is also an important measure for validation and

will thus be incorporated into the test plan.

Figure 9.Wireless Subsystem system schematic.


47/67


3.0 Wireless CommunicationSubsystem


Power Supply to GPS antenna Electrical and Signal transmission test

Power Suppy to Bluetooth Antenna Electrical and Signal transmission testProcessor to GPS Antenna (andreverse) Signal Transmission Test (Both Ways)

Processor to Bluetooth Antenna (andreverse) Signal Transmission Test (Both Ways)

GPS Antenna to Satellite Isolated connection test

Bluetooth Antenna funtionalityBuild test circuit, attach antenna, connect toperipheral device

3.0 Wireless Subsystem Verification

Send/Recieve data on both wireless

technologies, intelligent power supply test.Cycle on/off with power supply to ensure noextraneous current draw.

Figure 10.Verification and Validation for the Wireless Communication Subsystem.

User Input System

The purpose of the User Input System is to transfer data between the user and the device.

It is composed of two distinct components, the audio input (microphone) and the digital data

input (micro-USB port), as can be seen in Figure 11. The user input system requires a power bus

connection from the power control system, and is connected to the devices processor system.

The microphone will be required to sense the range of audible frequencies, as its primary use is

voice recognition. Furthermore, the microphone shall reject noise or undesirable signals as it is

important to prevent noise from propagating through the devices systems. The micro-USB port

shall adhere to its industry standards. Since the bus will be used for both power and data,

appropriate tests must be created, as mentioned in the verification and validation tests in Figure

12. Since the micro-USB port follows an industry standard, this component will see little to no

modifications for the devices purposes.


48/67


Figure 11.User Input Subsystem system schematic.

The verification and validation testing for the user input system is not safety critical, so

test cases will focus more on functional ability. The V&V test plan and components list can be

found in Figure 12, where the subsystem integration is listed at the end. It should be noted that a

system integration test for each subsystem will be conducted, though is not listed. This system

integration test (SIT) shall test the interaction and behavior of the subsystems connected together

in the device.


49/67


4.0 User Input Subsystem


Microphone Build test circuit, test range and sensitivity

Micro-USB PortSignal Integrity Test, Transmission AccuracyTest

4.0 User Input Subsystem Verification

Receive Sound Data from microphone andoutput on oscilloscope. Receive Data on USBand observe data on oscilloscope.

Figure 12.Verification and Validation Tests for the User Input Subsystem.

Display System

The purpose of the display system is to provide a user interface and acquire user

preferences and commands. The display system is implemented using existing advanced

projection technology, composed of the sunglasses visor and optics to provide a simulated screen

upon the lens of the device.

It can be seen from Figure 14 that the display system is composed more specifically of

special optical lenses, a light source, a color filter, a digital light processing (DLP) chip, and

information from the processor subsystem. In general, the optica

Documents

IE 5111 Systems Engineering Group Report.docx