Hasbro Project

Goswami, Raghav

NetID- rg698@cornell.edu

Systems Engineering, M-Eng ‘20

Mechanical Engineering, B-Tech ’19

With Special Thanks to-

Index-

PAGE
\*
 1. Introduction
2. Customer Value Proposition
3. Annotated Concept Sketch
4. Customer Affinity Process
5. Context Diagram
6. Use Cases
7. Use Case Behavioral Diagrams
8. Activity Diagram
9. Requirements Table-
i. Originating Requirements
ii. Derived Requirements
iii. Sysml Requirements
10. Concept Fragment Generation
11. Combination Tables
12. Functional Flow Block Diagram
13. IDEF-0
14. Decision Matrices
15. Goal-Question-Metric
16. Analytical Hierarchical Process
17. Quality Function Deployment or the House Of Quality
18. Sub-Systems
19. Operations Description Template
20. State Diagram & Matrix
21. Interface Matrix
22. Sequence Diagram
23. Behavioral Test Plan
24. Non-Behavioral Test Requirements
25. Verification Cross Reference Matrix
26. Severity & Likelihood Rating System
27. Risk Priority Number Table & Stoplight Graph
28. Failure Mode & Effect Analysis
29. Fault Tree
30. Parametric Diagram
31. Project Timeline

1. Introduction
We have implemented the concepts of Model-Based Systems Engineering in evaluating the design that
we have developed. By the use of Models, we can clearly distinguish between different domains and
aspects of the system, i.e., sub-systems, that cumulatively make up the system. Through this report, we

PAGE
\*
have documented the implementation of MBSE via computer simulations. This is particularly useful as it
makes the entire design process both easily accessible and understandable. Since there are a multitude
of different teams that must come together to actually make up a system, the simulation being
performed on computers is particularly pertinent in the current climate. We hope that this report would
suffice in demonstrating the usefulness both of Systems Engineering and the design for the system that
we are proposing.

2. Customer Value Proposition

From the Customer input data, it was identified that the top criteria for buyers of a toy are

1. Intellectually stimulating
2. Visually stimulating and auditorily pleasing
3. Complexity of toy parts
4. Purpose of the toy
5. Supervision required to play/use the toy

-To make the toy intellectually stimulating we added an entirely customizable body, an online persona of
each pet that can be used for help in schoolwork, and a responsive body to allow users how to interact
with animals in the real world.

-For the toy’s visuals and audio, we included bright vibrant colors to each customizable part, “cute” eyes
and a volume control knob, which would limit the sound being produced by the toy.

-With the toy body being completely customizable and being easy to assemble/disassemble we have
served the need for complexity of parts.

-The need for purposefulness of the toy was met by providing elements of companionship, learning and
group play into the toy via the feedback & responsiveness of the toy and the digital interface also
provided.

-To make the toy safe to use without adult supervision we included the cameras and sensors which
would inform and alert parents of unusual activity and by making the toy completely non-toxic and bio-
degradable

-Additionally, all these features and functions were then interconnected to meet the broader need of
allowing for more relaxation and stress-free time for the parents.

-Bridge the gap between children and seniors by designing a toy that serves the purposes of both target
audiences.

Log Line-
An animal-pet toy (simulating an animal) with an online interface for multiple gameplay environments,
customizable and configurable parts, cameras, sensors and motors to allow for an enhanced experience
of bonding and playing with a “pet”, while the pet itself provides with safety and security of the users.

3. Annotated Concept Sketch

This tool is used to bring to fruition the idea of the design. The annotated concept sketch is a rough
sketch of what the system would consist of, what parts go where and how they fit in conjunction with
one another. The annotated concept sketch allows us to peruse the “unique” features of a system, and

PAGE
\*
how the plan for working of the systems’ parts was assembled. This is divided into Functional and
Structural annotated concept sketch. Following are pictures of the annotated sketches of our system.

The functional sketch serves to show the Functional/Working Components (WC’s) of the system. These
show which parts of the system would actually be working and interacting with the user on some level
of interface. The changes in our sketch was based mostly on how our users would interact with the
system, and whom we hope would be using the system, therein, defining value in terms of the user.

Contrast this to the structural sketch, which aims to explain the structure of the system vis-à-vis,
abstract actions and events that the system would undergo during a period of use. Both of these
sketches define for the investor why and how we plan on designing the intricacies of the system. Our
structural sketches were also updated on similar user value-definition basis.

Although not included in our process, there also is the Storyboard tool- fleshing out a story in which we
define the use of the system, which would help to a much greater degree to visualize the working and
functions of the system.

Figure 1.1- Functional Annotated Concept

PAGE
\*
 Figure 1.2- Structural Annotated Concept

4. Customer Affinity Process

With the customer affinity data (responses from actual customers who would be using or purchasing the
system), we completed the hierarchical grouping. This tool helps us to streamline the wants of the
customers, to gain a perspective on the direction that design of the system needs to go in. We found this
tool to help us gain valuable insight, and saw that in purchasing toys for their children, customers want
something that helped in both helping children to valuably spend their time, while gaining some level of
intellectual stimulation. This was immensely helpful in coming up with our design, that seeks to
implement an online interface that would allow users to interact in games that would help both social
bonding and present itself as a means of learning. Beyond this, we feel that the systems unique way of
interacting with the user would allow for the user to gain knowledge and awareness on both animal
behavior and how living beings function. Further, to keep the system as entertaining as possible, we
hope to add functionalities that allow for group playing, and a sort of “collect ‘em all” feel to the system.

PAGE
\*
 Figure 2.1- Level 2 Sub-Grouping of Customer Affinity Process

Figure 2.2- Final Grouping

5. Context Diagram
The context diagram further shows us what we expect the system to represent in the lives of different
stakeholders. This tool was used in our analysis to demonstrate the relationships between the system
and different users- this required defining who our users would be. We did not limit ourselves in
establishing this userbase- in fact, we went on to include teachers and senior citizens in our context
diagram, the latter of which opened up a completely new user base that we believe our system would

PAGE
\*
be able to associate with. In designing for children, we found that senior citizens, particularly those with
neurodegenerative diseases would be able to interact with the uncomplicated design and model that
our system is aiming to develop into. Further, as most of the features, such as security, are required by
those who care for both infants and senescent individuals, we find that with proper marketing, our
system could effectively be a product that would run the gamut in terms of targeted users.

Figure 3- Context Diagram

6. Use Cases
With the defined user base and interactions to be expected amongst different users, and between the
system and the users, we now come to defining use cases. Basically, these serve as models of prediction-
how we anticipate the user to actually interact and use the system. This is especially useful in defining
the weak spots in our design, the fault lines within the system, and what it is that we should aim to
design for. The use cases posed to the designers the case wherein both teams of designers and
manufacturers would understand how our user base would use the system. In many cases, we would
find that though the main function of a particular system is prescribed, in very few cases would these be
the only ones that the system would have to endure. As such this tool gave us the opportunity to define
erroneous behaviors that could be demonstrated on the part of the user. In addition, the use cases gave
us a chance to define certain behaviors that we would need both testers and designers to be on the
look-out for.

PAGE
\*
 Figure 4.1- Use Cases of the System

A particular instance of the use cases is the SysML Use Case Diagram. A major part of the programming
and design for systems engineers is the use of systems tools, which we have accessed via sysml. These
tools are particularly helpful in-

1. Visualizing abstract notions

2. Defining and labelling interactions
3. Labelling placeholders for both users and use cases
4. Showing the versatility and fluidity of the system.

The sysml use case diagram is one the many sysml systems tools we have employed in our design of the
system, and through its deployment we understood why systems tools are required in the design
process. Beyond the stipulated points, in our case in particular, the use case diagram shows us the
different interactions which would actually define our system, and how these functions related to the
end-user.

PAGE
\*
 Figure 4.2- Sysml Use Case Diagram

6. Use Case Behavioral Diagram

The Use Case Behavioral Diagram is a functional flow diagram that elaborates on the use cases that we
have obtained and helps in setting standards by which the system “shall” function. It consists of three
parts- The user, the system, and the Working component that is being referred to in the diagram. The
UCBD is a definition for the precedence in which actions will occur once the user begins a particular type
of interaction, how the system is supposed to respond to the action, and finally the response from the
relevant component in the particular use case. Through our UCBD’s we were able to generate
requirements for our system- these are basically the building blocks that guide what actions are system
will have to do in order to conform to the needs of the interaction that has been triggered by the user.

PAGE
\*
Figure 6.1- Use Case Behavioral Diagram 1

Figure 6.2- Use Case Behavioral Diagram 2

PAGE
\*
Figure 6.3- Use Case Behavioral Diagram 3

PAGE
\*
 Figure 6.4- Use Case Behavioral Diagram 4

7. Activity Diagram
This is a special case of the UCBD- using sysml we define a particular activity (use case) and
demonstrate, visually, the flow of the actions, events and the requirements of the system for the
corresponding activity. From the picture below we can observe the way that the three components
interact with each other, the requirements acting as a sort of buffer between the other two members.
Again, the sysml activity diagram helps keep the entire activity more succinct and is definitely more
palatable than dry words on a blank canvas. Further, the underlying intention of using sysml tools, which
will become easier to observe as we move forward with the report, is the inter-communication amongst
the different tools we use for design, which allows for much greater accessibility and clarity when
designing or implementing the system.

PAGE
\*
Figure 7.1- Activity Diagram 1

PAGE
\*
Figure 7.2- Activity Diagram 2

Figure 7.3- Activity Diagram 3

PAGE
\*
 8. Requirements Table
By now, our system begins to take on some form or shape similar to what the final product should look
like. As such, we now have several requirements that we expect our system to fulfil so that it actually
functions in the intended way. Although some of the requirements are objective and need little to no
further clarification, there are some abstract requirements, that have parameters that can be defined
only in a later stage of the design life cycle. There are three tables of requirements that our design
process implemented.

i) Originating Requirements
These are the requirements that have been gathered from the UCBD’s and Sysml Activity Diagram.
These are the building blocks, in terms of functionality of our system. They are a set of codes that govern
the way we expect the system to behave. For our system, this tool helped us in identifying a crucial
feature of the system that we are developing, which will be fleshed out even better as we progress with
the report- our system is dependent largely on electronics. Most sets of key functionalities depend on
using electronics to help users gain a more interactive experience, as well as in helping establish more of
a niche user-system interaction.

Figure 7.1- Originating Requirements

PAGE
\*
ii) Derived Requirements
The design process in filled with hindsight and revisions- the derived requirements tool is testimony to
this fact. Having implemented a separate tool (known as the operations deployment template,
described later in the report), we find that as we narrow down the spectrum of possible states that our
system could be present in, there are a whole new set of requirements that need to be established, to
keep these more specialized functionalities in mind. Thus, we obtain the derived requirements- as the
name suggests, these are specialized instances, that are crucial enough to need independent
description, of the former originating requirements. They are named in a way that it becomes clear
which derived requirement is related to which originating requirement.

Figure 7.2- Derived Requirements

iii) Sysml Requirements

Using the Sysml activity diagram, we obtain a third table of requirements- this one is composed entirely
of the requirements that the sysml activity diagram generates.

PAGE
\*
 Figure 7.3- Sysml Requirement

9. Concept Fragment Generation

The concept fragment generation, in conjunction with the combination table, help us establish and
define the tools and components of the system. This table shows us possible ways in which we could
satisfy different physical requirements of our system. In our case, we had few alternatives for the
electronic components of the system, which led us to establish this tool for uses in physical components
of the system, such as power generation, power storage and transfer. We created an exhaustive list of
possible alternatives for various parts of our system. Although some of these may seem peculiar, in the
spirit of keeping all options open and creating a truly exhaustive list, we have used this tool to help us
narrow down on which alternative would be most beneficial to be used amongst the list of different
alternatives.

PAGE
\*
 Figure 9- Concept Fragment Generation Table

10. Combination Table

Having completed the concept fragment generation, we use the information in this table to form the
combination table- interaction amongst different functional components and the alternatives specified.
This essentially helps us in define multi-purpose uses of a single fragment. It also helps, as in our case, to
see that the method of implementation of power transfer could also be used in customization of the
system by user. This information helps in design of the system to become more streamlined, and in
keeping wastes of manufacturing to a minimum.

Figure 10- Combination Table

PAGE
\*
 11. Functional Flow Block Diagram
The functional flow block diagram is one of the tools that begins to define different actions that the
system would be expected to perform in conjunction with each other. This includes a hierarchy of how
the activities would flow, how groups can be formed from different activities- one feature of the FFBD is
the establishment of logical controls. Typically, there is one that begins the control, and another
instance that signifies the end of the control. IT- iteration; this is basically a designation of repetition of
certain actions, and the precedence in which each iteration would occur; AND- parallel sequence;
showing two activities/chain of activities that would occur concurrently; OR- branching sequence; shows
a fork at which the system proceeds towards either of multiple ways. The FFBD helps in establishing the
logical sequence of our use cases and actions that the system would display. As mentioned earlier, our
system would use these tools to establish the dependence on electronics that makes our system unique
in the segment. This tool helps our system to become more fleshed in terms of defining relations
between use cases/actions and how we expect the system to perform these actions. There is another
tool that helps in establishing precedence of activities in the system.

Figure 11.1- FFBD Level 1

PAGE
\*
 Figure 11.2- FFBD Level 2

12. IDEF-0
This is the other function modelling tool. Significant difference between the IDEF0 and the FFBD is the
fact that there is more importance given to inputs, outputs and requirements for specific functions, as
opposed to the absence of these in the FFBD. In fact, each block of the IDEF0 contains information
pertinent to the specific block, that would be required by any designer. Another difference is the inter-
relation amongst the blocks themselves- the hierarchical pattern is very clearly demonstrated in the
IDEF0, with the ability to expand on inner flows, by accessing the exterior blocks in the upper levels. In
the pictures below, we show three levels of our systems’ IDEF0. Notice that here there are several
arrows pointing vertically and horizontally, into and out of the blocks. These are (clockwise from the top
arrow) – Control/Constraint, Output, Resource/Mechanism, Input. The Control shows information of
factors that influence the activity, while the Resource tags show entities that are simply being used by
the system, while not being consumed or transformed.

PAGE
\*
Figure 12.1- IDEF-0 Level 1

Figure 12.2- IDEF-0 Level 2

PAGE
\*
 Figure 12.3- IDEF-0 Level 3

13. Decision Matrices

The decision matrix is a criteria evaluation tool. There are criteria that we select to elaborate our system
on- these can be derived using the customer affinity data, intuition, competitor data, or any other
apropos method of gathering insight about the systems functionality. With these defined we proceed to
evaluate the desirability of different possible alternatives. While there are objective criteria, that are
relatively simple to define and flesh out on, there are also subjective criteria, that require to be
enumerated based on established methods of quantifying the desirability of any particular criteria. In
our case we see the results of the matrix, and that option B would be the most desirable option. Here,
however, lay one of the pitfalls of this tool- the inherent subjective nature of the decision matrix, implies
that there should not be over reliance on the results, they should only serve as a stepping stone to gain
insight on the direction that the design should take. Over emphasis on the results of the matrices will
surely result in short sight of crucial details on the development of the system. Further, we have
graphically demonstrated the desirability of the three alternatives that we have considered. The
Decision matrix also ushers in the need for an ally tool, the Goal Question Metric. Using these two tools
in tandem tends to produce more accurate and reliable results than using the Decision Matrix in
isolation, however, again it would be more prudent to gather more insight, and also test out the real
world effectiveness of the theoretical numbers put forward in these two tools.

PAGE
\*
 Figure 13.1- Decision Matric Final Level

Figure 13.2- Measurement Scales for the Decision Matrices

Figure 13.3- Measurement Scale Continued

PAGE
\*
 Figure 13.4- Graph for the decision matrices

14. Goal-Question-Metric
With the GQM we begin establishing a system of feedback as to the effectiveness and working of the
planned design of our system. We begin with the insights gathered from the customer affinity process of
grouping together different options. These are the criteria that we aim to establish in our system. We
then proceed to establish questions that would allow us to gain the answers to these criteria from the
users. It must be noted here, that to have an effective design process, at least some, if not most, should
allow for insight and feedback for the systems’ effectiveness, before the final stages of production and
deployment; this is to help keep the goals and progress aligned, to prevent for scope creep and to keep
an updated team of designers. Now we work on the metrics of establishing answers to these questions-
there are two columns- ideal metric and approximate metric. As the names suggest these are just ways
of quantifying the results/answers of the questions- the former defining which would be the best, but
non-feasible, way of gathering input, the latter giving a more practical way to proceed with the
gathering of data. With our GQM, we have established some way to ensure that our system would still
be desirable to the user base, even without some of the features that would be added in later/final
stages of development. An additional point- we had to choose amongst the various insights from the
customer affinity process, setting a means in which to define our system in a more unique/narrow
spectrum, thus establishing a definite skeleton to our yet nascent system. The next step would be to
fully establish precedence amongst the different goals that we have.

PAGE
\*
 Figure 14.1- GQM 1

Figure 14.2- GQM 2

15. Analytical Hierarchy Process

This tool is used to give preference to the different goals that our system is setting out to achieve. As we
are defining our system into a set mold, it becomes necessary to determine what need we are trying to
solve with our system- the AHP helps in this to a great extent. Caution, again, on over-reliance on the
numbers. As the numbers that any individual would prescribe to the different goals, has a very slim
chance of perfectly coinciding with those of another individual, there is bound to be some discrepancy in
the numbers. However, by taking average assumptions, these can give some concrete direction in which
to progress. We begin by writing down goals an any sub goals that can be derived from these goals.
Then we set to give each of these goals precedence by designating some fraction of 1 to the particular
goal. We multiply the weights given to a goal and the subsequent weight given to sub goal to obtain a
precedence. This is marked as ranking in the picture below. We now have a sense of what it is that the
users we are targeting would describe as most desirable in our system.

PAGE
\*
 Figure 15.1- Analytical Hierarchical Process

Figure 15.2- AHP Ranking

16. Quality Function Deployment

Also known as the house of quality because of its shape, reminiscent of a slant-roofed house, this tool is
used in quantifying an important aspect of any design- the engineering characteristics. These are unique
characteristics that would enable physical functionality of the system to be demonstrated. However,
these aren’t the only important aspect of the QFD- the tool helps in other key areas, namely, definition
of customer objectives, and looking at the behavior of competitors to see how feasible the design would

PAGE
\*
be in the real-world market. It also sets relations between the how the customers desirability of our
product would increase or decrease, with a change in quality of an engineering characteristic. These
tools are used to ensure that our idea, or our system, should be given importance to. In fact, this entire
report shows us why it is that the system that we have designed is to be funded, and the QFD helps in
setting up this to an even greater extent, by juxtaposing our system with competitors. For the
competitors, we use a simulated version of the AHP to figure out how our system fares against the rest.

Figure 16.1- QFD Performance Criteria and the House of Quality

Figure 16.2- QFD Customer Perception

The ‘basement’ of the house of quality is quantified data on all of the systems. This includes
characteristics like weight, volume and also includes more subjective information such as quality of
camera and microphone. In the basement, we see the importance that each individual engineering
characteristic must be given and how they fare against those of the competition.

PAGE
\*
 Figure 16.3- Basement of the QFD

17. Sub-Systems
In any complex design, it is seen, that in development, there needs to be specialization and specification
of major components of the system. In the systems design process, we achieve this specialization via
sub-systems. This information however is used in collaboration with interfaces, which we will cover
later. Subsystems are parts of the independent parts of the system, that are important enough to
necessitate a separate division and definition. We begin the table by looking at our system and figuring
out which components would justify a subsystem. In our system we see that there is a lot of aligning of
the different audio-visual components. We have defined the subsystems, not with the intention of
conformity, rather to be as exhaustive in our definition of the systems separate component parts. Here,
one of the points made earlier on become quite clear- there is a great dependence of our system on
electronics. Now, this was foreseen, as we are trying to simulate a real-world experience, without much
or any of the responsibility. As such, this requires that we use electronics to achieve the same. In
addition, the subsystems show how we are choosing to separate the different major components of our
system, and even though some the elements are seen across various subsystems, this is necessary when
thinking of the teams that would develop these systems- it is necessary for the different teams to
understand how and with whom they would be cooperating with. With the subsystems defined, we
move into the more crucial functional aspect-the operations deployment template

Figure 17.1- Sub-systems Definition and Allocation

PAGE
\*
 Figure 17.2- Sub-System Cont.

18. Operations Description Template

The structure of the ODT is reminiscent of the UCBD, and in fact, there is a hierarchy and precedence
prevalent in the ODT. The purpose of the ODT is to-

i) Establish new/revised requirements,

Figure 18.1- ODT 1

ii) Define the actions performed by operators, as a means of establishing specific interactions between
user and system,

PAGE
\*
 Figure 18.2- ODT 2

iii) Specify how the subsystems come into play with each use case, more specifically, using this
information to develop the Derived requirements,

Figure 18.3- ODT 3

iv) Define States of our system,

Figure 18.4- ODT 4

PAGE
\*
v) Define and elaborate on a physical aspect of the working of the system- in our case, power
consumption per action.

Figure 18.5- ODT 5

The ODT is thus, a more structured and detailed flow diagram. States in particular show us the entire
working range of our system- these are assumptions of how we perceive the system to behave to a
particular interaction being triggered, and how they behave, prior to the action, and after the action has
been completed.

Figure 18.6- ODT 6

PAGE
\*
 Figure 18.7- ODT 7

19. State Diagram & Matrix

The states that we have obtained from the ODT are used in this tool to show the differences within the
states, how they occur and, using these two pieces of information, how they relate to one another.

Figure 19.1- State Diagram

PAGE
\*
 Whereas the state diagram is, as can be inferred, a diagrammatic representation, the matrix is a table
that uses the information in the diagram and is presented in a tabular form. In addition to arrows
representing changes, the conditions that trigger these changes are also described

Figure 19.2- State Matrix

20. Interface Matrix

Going back to the subsystems, an interface is an instance when two subsystems affect each other in an
action performed by the system. The interface matrix, also known as the N2 matrix, shows the
interaction between the interfaces in a particular action sequence or instance of the system. The matrix
consists of how the interfaces are related and the medium/type of information flow that occurs
between the two subsystems. One drawback is interactions amongst more than two subsystems in
conjugation. This, more often than not, implies that a review of the subsystems is to be considered, as it
is probable that perhaps there are enough similarities between two subsystems that they can be
considered under the purview of a single, broader subsystem. In our system, this was not observed as
can be observed below.

PAGE
\*
 Figure 20- N2 Interface Matrix

21. Sequence Diagram

The sequence diagram is another sysml tool that demonstrates information and action flow amongst the
various subsystems. It is characterized by the subsystems being addressed, how information flows
amongst them, and other system data that is necessary for the sequence of the action to be described.
An operator, called user, triggers the sequence by an initial action and the diagram demonstrates this
flow, including how it would terminate. The solid lines designate any information that has been created,
or information transferred, while the dashed lines represent return values of a particular action being
completed. In the creation of the sequence diagram, it has become clear that the interfaces would need
to be defined so as to avoid miscommunication amongst different teams. The role of Data would play a
major role in our system, which has become clear in the construction of the sequence diagram-
regardless of the type of action that the system would be expected to perform, it would need to be
updated on the data log, and as such, for the system, memory capabilities and data storage would be
quite important, in terms of quality, quantity and duration of transfer. There is also the additional use
case of erroneous action that needs to be considered, in terms of how critical functions may be used
erroneously. The Algorithms would define to a huge degree whether the system would work as per plan;
the command codes would be acting as the actions that system would perform.

PAGE
\*
 Figure 21- Sequence Diagram

22. Behavioral Test Plan

Testing is by far the most important part of designing. Thus, an equal importance is given to planning
out how the actual testing would be expected to unfold. The Behavior Test Plan is a comprehensive tool,
that has allowed us valuable insight on how we would determine effectiveness of the design, whether it
would work under certain anticipated erroneous use conditions. The Test Plan consists of Testing
Procedures- how and what we are testing. These procedures are based on all the requirements we have
established up till now. Thus, we are testing for the efficacy of the system to uphold the requirements
that it is subject to. The Test plan includes the test method- how we would perform the test of the
particular requirement. In many instances, before beginning major investment on a design, it is
important to find substitutes to help test out critical requirements that the design must be able to
uphold. This is why we have used vegetables and fruit to help us simulate the structure of our system.
The verification method, is a definition of what kind of test we would be performing- these include,
Analysis, Inspection, Demonstration and Physical Test. As inspection is a more passive validation
method, and the formulation of the Behavior test plan we have developed hinges on the structural and
function integrity of the system and subsystem, we do not currently employ the inspection validation
method. In fact, most of our test would be validated via demonstration. The Entry condition is the state
in which our testing facility/equipment will be in prior to the actual testing. There are many different
states that the system could be in depending on the type of test being performed. More critical is the
exit condition- the states that persists after the test has been completed. This defines the feasibility of
our design.

PAGE
\*
Figure 22.1- Test Plan 1

Figure 22.2- Test Plan 2

PAGE
\*
 23. Non-Behavioral Test Requirements
Non-Behavioral requirements are those requirements that are dependent on exit conditions rather than
how the system behaves. For example, a test for ensuring that the system moves at a maximum of 7
meters/second is a non-behavioral test requirement

Figure 23- Test Plan Cont. (Non-Behavioral Test Requirement)

24. Verification Cross Reference Matrix

This is just a way of checking which TP relates to which requirement. It allows for accountability of the
test plan, and also helps ensure that all of the requirements have been tested, allowing for a
straightforward way to check out the particular TP that corresponds to any requirement.

Figure 24- VCRM

25. Severity & Likelihood Rating System

These two rating systems are inter-related; they are used defining failures in the system. The Severity
system composes of how we define different degrees of severity- how severe any particular event would

PAGE
\*
be on the system. This is further divided into definition by failures of the system, which is described in
the last sections of the report. We used a 1-10 rating system for severity. We feel it was important to
define it as such as severity is something that could be scrutinized to a great extent in our system.

Figure 25- Severity Rating System 1

PAGE
\*
 Figure 25.2- Severity Rating System 2

The Likelihood system is a measure of how probable the event described above is likely to occur. We
used a 1-5 system for the likelihood. Although it may have been more pertinent to use a similar system
here as for severity, we think that the likelihood being less wide, allows for greater categorization and
grouping of critical accidents to the system.

PAGE
\*
 Figure 25.3- Likelihood Rating System

26. Risk Priority Number & Stoplight Graph

The risk priority number is the product of the severity and likelihood of any particular action that has
been performed on the system. For our system, we had a minimum possible of RPN of 1 and maximum
of 50. Between these two extremes, we create the stoplight graph, that shows the transition between
actions of varying severity, thus giving us a sense of low, medium and high criticality. The RPN is a
measure of criticality of an action and event. With the information of the RPN we proceed to construct
the stoplight graph, that diagrammatically and visually represents where the failure would place
between 1-50. If there are several failures in the high criticality range, the system is probably one that is
fragile and needs to work more on robustness and strength.

PAGE
\*
 Figure 26- RPN & Stoplight Graph For the FMEA

27. Failure Mode and Effect Analysis

The severity, likelihood, RPN and criticality are all used to demonstrate the failure mode and effect
analysis. This is a tabular representation of the various modes of failure that could occur in the system. It
consists of identification of the function, i.e., which aspect of the system is being scrutinized in the
particular failure mode being elaborated upon. These functions are then divided into failure mode, how
the function or part fails. Then we describe the effects of the failure on our goals for the system- there
are three main effects- mission, system and local. Local failures are the least worrisome, as they
represent failure of a particular function and would be the least expensive to fix. System failure signifies
the failure of a greater component because of the failure of many local parts. Finally, mission failure
implies a failure of the system to retain any semblance of the system, and inability to work normally at
all. When we have evaluated these effects, we move on to corrective measures- operation,
manufacturing and design. Design fixtures are the lengthiest and require the most effort, as there would
be some aspect of the actual design of the system that would need to be fixed in order to overcome the
failure. Manufacturing fixtures are those that require a revision and review of how we are
manufacturing the parts of the systems. Operation fixtures are more changes in behavior that we need
to correct. Along with all this information, we have the column of possible causes- why the failure took
place at all. The FMEA helps us in establishing erroneous operation and usage of the system which is
crucial to both the testing and production process.

PAGE
\*
 Figure 27.1- FMEA 1

Figure 27.2- FMEA 2

28. Fault Tree

The fault tree is a diagrammatic and mathematical model that shows the flow of failures, and their
effects on the system. In the case of our system, we had to assume the probabilities based on intuition
as we have not had a chance to actually test out the cases. Again, the emphasis needs to be made, that
although the system can still be used, however, a failure in electronics would mitigate most of the
planned functionality of the system, and as such we have focused on this aspect of the system in our
fault tree. We have in our system made assumptions of the probabilities of the failures, based on
speculation, as practical data does not yet exist, however, we would like to point out that these
numbers would be close to actual numbers when considering the unique nature of the failure cases that
we have elaborated on.

PAGE
\*
 Figure 28- Failure Tree

29. Parametric Diagram

Finally, we have the parametric diagram- it is a sysml tool that is used to demonstrate equations and
relations between various components of a sub-system/system. In our example, we have focused on
making equations relating to the mobility and audio capabilities of the system. Although there is a
cumbersome quality to this particular tool- as the complexity of the tool progressively increases, the
number of equations increase, making it hard to distinguish the different distinct parts of the system
being referred.

PAGE
\*
Figure 29.1- Parametric Diagram for Motion of the System

Figure 29.2- Parametric Diagram for Sound of the System

PAGE
\*
 Figure 29.3- Parametric Diagram for the Energy Used

30. Timeline update

With the completion of the Parametric Diagrams, we have finished the conception of the design for our
system, and can now move on to the development of subsystems and matrices of the system. At this
point, we can expect more development of individual components of the system, and subsequently we
can begin the testing of the system to ensure that the targets that we have set for the system are
realistic and achievable. A crucial point for this would be proper communication amongst the various
teams developing different interfaces and as such we should plan to choose good interface champions.
Beyond this we must also look at where and how the overlaps between different interfaces occur, and
the rules and settings that each have to adhere to.

The first deliverable to be looked at is the formation of the skeletal structure of the system, to ensure at
the very least that the design is physically feasible and structurally achievable. We have taken time to
account for any discrepancies that may occur during the process, because of the particular time of the
year. However, we are confident that this stage would be finished well within the stipulated deadline.
The final prototype of the body is one of the first important deliverables in the design process

Figure 30.1- Timeline Update with Deliverable #1

PAGE
\*
With the first deliverable complete we would look to develop the main functionality of the system, i.e,
the electronics and the interactive element of the system. We are assuming that this would take a bulk
of the time, and would involve extensive testing and cross-checking for optimal performance and
activity. At the end of this stage, our second deliverable would be realized- the working of the various
electronic components of the system. This involves individual working of each component and also each
separate component working in tandem with each other to give us a model that could be likened to our
final vision of the system. This would also mark an important stage of the design process, as here we
would know the feasibility of the project, and whether or not it should receive effort and funding.

Figure 30.2- Timeline Update with Deliverable #2

PAGE
\*