Page 1

Hasbro Toy Project CARTER the Transformer

Mohammed Sameed Shafi ms2788@cornell.edu Electrical and Computer Engineering, M.Eng.’14


Contents List of figures ............................................................................................................................ 2 Introduction .............................................................................................................................. 3 1.

Customer Affinity Process ................................................................................................ 4

2.

Concept Sketch .................................................................................................................. 4

3.

Context Diagram ............................................................................................................... 5

4.

Use Cases........................................................................................................................... 6

5.

Use case diagram............................................................................................................... 6

6.

Use case Behavioral Diagram and Activity Diagrams ..................................................... 7

7.

Originating and Derived Requirements + SysML Requirements Table .......................... 8

8.

Functional Flow Block Diagram (FFBD) .......................................................................... 9

9.

Concept Fragment Generation and Combination Table .................................................10

10.

IDEF0 ............................................................................................................................10

11.

Decision Matrix .............................................................................................................11

12.

Goal Question Matrix (GQM) .......................................................................................11

13.

Analytical Hierarchy Process .......................................................................................12

14.

Customer Value Proposition (CVP) ..............................................................................13

15.

Quality Functional Deployment (QFD) ........................................................................13

16.

Subsystem Definition and Allocation ...........................................................................15

17.

Operational Description Template ...............................................................................15

18.

State Diagram and Matrix ...........................................................................................16

19.

Interface Matrix ............................................................................................................17

20.

Behavioral Test Plan ....................................................................................................17

21.

Non-behavioral Test Plan .............................................................................................18

22.

Verification Cross Reference Matrix (VCRM) ..............................................................18

23.

Failure Modes and Effect Analysis (FMEA).................................................................19

24.

Severity Rating System and Occurrence Rating System .............................................19

25.

Risk Priority Number Table, Criticality Rating System, Stoplight Graph .................20

26.

Event Trees and Fault Trees ........................................................................................21

27.

SysML Parametric Diagram .........................................................................................22

28.

Timeline ........................................................................................................................22

Appendix A - Attached excel file

Appendix B - Attached PDF file Page | 1


List of figures Fig. 1. Customer affinity process sample classification Fig. 2. Sample toy relationships with systems Projectiles and stakeholder pet Fig. 3. Sample Use case diagram depicting behavioral relationships Fig. 4. Sample SysML activity diagram Fig. 5. Originating Requirement OR.21 Fig. 6. Sample SysML requirements diagram Fig. 7. Functional Flow Block Diagram example. Fig. 8. Concept combination tables Fig. 9. Snippet of IDEF0 level 2 Fig. 10. Sample entries from GQM Fig. 11. Sample columns from the Analytical Hierarchy Process Fig. 12. Relationships between engineering characteristics Fig. 13. Rating the CARTER transformer toy with competitors Fig. 14. Objective measures and targets Fig. 15. Snippet of ODT detailing interface rows Fig. 16. State transition diagram Fig. 17. Sample Interface matrix entries Fig. 18. Sample behavioral test plans Fig. 19. Sample non-behavioral test plan Fig. 20. Sample FMEA entry Fig. 21. Severity rating system Fig. 22. Occurrence rating system Fig. 23. Spotlight graph Fig. 24. Snippet of event tree for event – “No sound from toy” Fig. 25. Parametric diagram for Sound Intensity Fig. 26. Snippet from Hasbro Project Timeline

Page | 2


Introduction A gap exists between the values expressed in informal specifications in terms of parameters familiar to many engineering disciplines. Systems engineering helps bridge this gap by ensuring that the customer’s needs are always kept in mind throughout the development of a product. With an array of tools able to assist him, a system engineer is able to: 1. Understand the customer’s needs. 2. Discover, validate and verify the requirements, both at a structural and functional level. 3. Evaluate a variety of solutions available to him by using models and matrices 4. Model the system based on these requirements and evaluations 5. Integrate the various subsystems which are identified, as most of the issues occur when connecting subsystems at their interface. 6. Assess the performance of the product against a set of metrics which hold the customer’s requirements in focus. An important point to note is that systems engineering is an iterative process with various tools feeding into each other. It is also necessary to keep updating these tools to ensure their maximum benefits. SysML is a systems modeling language, an extension of UML (Unified Modeling Language). For this report, SysML diagrams were developed using the OpenModelica software and the plugins developed by Prof. Peter Jackson, Cornell University.

Page | 3


1. Customer Affinity Process To define a system, critical information is usually obtained from the system’s users. This information’s is mostly in informal language, with abstract definitions of what the customer’s actual functional need is. The role of the customer affinity process is to hierarchically organize this information so that a broad overview of system’s targeted functionality arises. An important point to learn from this process is that the product cannot target each and every need of the customer, and that decisions need to be made to prioritize which of these the product needs will focus on. In the customer affinity process, care was taken to ensure that the final hierarchy is not bland and that the customer’s voice can still be heard from the final level definitions. In the CARTER transformer project, the customer affinity process helped identify key areas of “cool” looks and an “interesting backstory”, the first of which are common in most toys, but most toys do seem to lack the second one. Integrating this toy with the rest of the Transformers universe provided a good opportunity to focus on. Another important factor identified was that simple requirements such as “be available in multiple colors” act as a low hanging fruit, which can be obtained without a rigorous design process behind them. Use of this tool led to further design work in figuring out not only the functionality of this toy, but to identify that even though a lot of customers did not mention ‘safety’ as their top priority, it was inherent that the product satisfy the highest safety standard available, which is what they have come to expect from a company as prominent as Hasbro.

Fig. 1. Customer affinity process sample classification

2. Concept Sketch Concept sketch is both used as a first level design point for the product, as well as the target for the final design of the product. The concept sketch comes in two versions – structural and functional. The functional version highlights what is the customer’s need which has to be met, what the product must do, how the various subsystems interact and how the product’s performance is measured. On the other hand, the structural version clearly identifies how the product is going to meet the identified customer needs, an overview of how the subsystems Page | 4


are implemented and what is the system’s actual performance on the identified metrics. Locking in to a design early is dangerous because then changes down the line would incur increasing costs, while at the same time imposing additional difficulty. On the CARTER transformer project, this tool helped identify superfluous features, that is features which were not satisfying the customer’s targeted needs but were more focused on the designers target of adding extra functionality. This tool also helped define the key features of the product, namely the additional attachments and the variability in the transformer’s look which they added to. This led to further design work in identifying which animal attachments would suit the product better, and these are discussed in more detail in the Decision Matrix Section.

3. Context Diagram Context diagram as a tool helps in identifying the systems key relationships with all the major stakeholders involved. It also assists the design group in establishing the boundaries within which to design the product, as well as focus not only on the customer’s needs but also to satisfy and external factors such as government regulations. For the CARTER transformer project, regulatory requirements of the ‘Consumer Product Safety Act’ were identified as an important relationship to getting the product to the market in time. Another important factor which this tool highlighted is the importance of formatting while submitting these documents for review. Government and regulatory authorities demand strict adherence to formatting and that key feature is now maintained among all the tools attached in this report’s appendix B.1.

Fig. 2. Sample toy relationships with systems Projectiles and stakeholder pet

Page | 5


4. Use Cases Use cases provide an insight into all possible ways that the system could be used. They highlight not only the intended uses but can also identify unintentional or even potentially hazardous uses of the system. Using the context diagram and the concept sketches as a starting point, designers seek input not only from the customer, but also base their input from past projects, similar projects at competitors as well as peers within different teams. For this project, the certain uses are highlighted as ‘high priority’ and given more focus. These are the main functional properties of the toy, and its main intentional uses. The medium and low priority use cases are not forgotten, but are always kept in mind while working on the system’s design as they can later be identified as potentially high priority use cases. Use of this tool further led to improving the durability of the product to minimize the loss of functionality that the product can face when put through its unintentional uses.

5. Use case diagram The use case diagram depicts the possible interactions between the operator and the designed system, and also a behavioral look at the relationships between the use cases. It assists in identifying the relationships that specific operator has with the systems, such as ‘extend’ – which might be a special case of an earlier identified use case., ‘include’ – where a use case might be a subcase of an earlier identified use case, and ‘trigger’ – where one use case can lead to another. For this project, this tool helped classify use cases in which the actor ‘Parent’ plays an important role in explaining and teaching the actor ‘child’ the functionality and intended use of the toy system. This tool led to further design work in identifying the exact behavior of each use case, which led to the development of the next tool, the Use Case Behavioral Diagram. A snippet for the Use case diagram built in SysML is shown in Figure 3.

Fig. 3. Sample Use case diagram depicting behavioral relationships

Page | 6


6. Use case Behavioral Diagram and Activity Diagrams The use case behavioral diagram details the behavioral interaction between the operator and the system. It focuses on what is required of the system functionally, not structurally. At a high level, it gives a description of how the system must behave for this particular interaction between the operator and the system. A use case behavioral diagram is also referred to as an Activity diagram and can be built in a UML tool, a snippet of which is shown in diagram X, while the complete screenshot is available in appendix B.8. The difference between the SysML version and the excel version is mostly in terminology, and that the SysML version is able to capture the flow more comprehensively using directional arrows. For the current toy system, this tool helped identify the constraints for the starting and end conditions for this operator-system interaction, as well as the control flow in the system’s behavior to this interaction. Also, the tool helped identify other components involved in this interaction, namely the animal attachments and the projectile robot fists. This tool led to further design work in identifying a high level functionality of the subsystems which will be involved within the toy system to correctly carry out this interaction.

Fig. 4. Sample SysML activity diagram

Page | 7


7. Originating and Derived Requirements + SysML Requirements Table Originating requirements are those requirements which come from the customer directly. They can be sourced from the customer provided RFP, any meetings with the customer and any further interactions with the customer. Derived requirements on the other hand are obtained while working on the design of the system. These come mostly from any interactions between the subsystems. Most of them are kept internal to the design team, but it might be a good idea to cross-verify important ones with the customer to ensure that the design is on the correct track. An important concern is that both these categories of requirements be unambiguous, clear, precise, objective (clearly measurable and verifiable) and consistent with other requirements. Using this tool for this project, it was important to identify not only what the requirements were, but also to make sure that there was a way to verify the said requirement. Requirements such as OR.21 were defined but since the final design was not complete, placeholders such as ‘SHOOT_DISTANCE’ were inserted and the cross-listed in a requirements constant definition table to make sure that these placeholders were updated once their values were available. An important point to remember is that the determining requirements process is iterative, and that any requirements identified further down the design process is updated not only in these tools, but spread to the entire design team. This tool led to further work in developing later tools such as the ODT and the concept fragment generation. OR.21

The system shall be able to shoot projectiles up to a distance of SHOOT_DISTANCE Shoot

Fig. 5. Originating Requirement OR.21 The requirements can also be tabulated using the SySML tool and this version is called the SysML requirements diagram. As can be seen in Figure 6, this diagram captures similar information as the excel version, but also specifically mentions in each tab that this is a requirement. It places more emphasis on the short name of the requirement and can be linked to other system engineering tools available in SysML.

Page | 8


Fig. 6. Sample SysML requirements diagram

8. Functional Flow Block Diagram (FFBD) A use case behavioral diagram gives an idea of how the system’s behavioral events are connected in time and how they are triggered. The FFBD on the other hand provides an insight into the logical flow of the system’s functions. In the diagram, there’s a general leftto-right hierarchical flow of functions, with the relationship between functions being defined by logical elements such as AND, OR and iterative LOOP connections. Using this tool on this project helped identify parallel paths that the system could trigger from a same starting point (as depicted in Figure 7). The tool also helped better define the logical sequence of the toy operation, which can be traced in an end-to-end path. The tool led to further design work in analyzing the core functionality of the toy system, as well as any design parameters which might affect the order of this flow.

Fig. 7. Functional Flow Block Diagram example.

Page | 9


9. Concept Fragment Generation and Combination Table While analyzing the originating requirements, it is important to develop what the options are for a particular choice of design. Concept fragment generation achieves that by not only allowing the designers to keep track of design choices, but also providing a section (see notes in diagram) of why a particular design choice was pruned. The point being that a pruned idea might trigger an idea later on in the design process, or at least provide justification if required later on. On this project, this tool helped classify the different solution for subsystems design such as the locking subsystem and the robot fists projectile system. This tool then led to further design work in the combination table, which is talked about next. Another important parameter when analyzing the various options for a subsystem is that which combinations from different requirements can actually work together. The combination table provides details of these valid combinations (As can be seen in diagram). This tool was used on the project to identify the optimum configuration for the locking mechanism between the animal attachments and the robot subsystem. A final selection of the mechanism was then determined using a decision matrix (more of which is talked about in section X).

Concept Combination Table The system shall contain a locking mechanism to secure the attachment Crossbar bolt Plastic pins Spring latch Screw Key Metal pins

The system shall allow the release of existing attachment by unlocking the locking mechanism Push or pull force Mechanical switch Electrical switch Tools

The system shall allow the The system shall contain a release of existing attachment locking mechanism to by unlocking the locking secure the attachment mechanism Crossbar bolt with push or pull force Plastic pins with push or pull force Spring latch with electrical switch Spring latch with mechanical switch Screw with tools Key with tools Metal pins with push or pull force

Fig. 8. Concept combination tables

10. IDEF0 IDEF0 is a tool which has its origins in the US Air Force. It is characterizes the systems functions with respect to its inputs and outputs. The IDEF0 also highlights the availability of the function with respect to the resources required for that function, as well as the constraints which are applied to the same function. The IDEF0 follows a hierarchical process, but an iterative approach is recommended in that any details identified at lower levels must be propagated to the higher levels. At a high level, the IDEF0 allows the design team to focus on what inputs/outputs will result in each stage, plus create a hierarchy of what gets done in each stage. On this project, the IDEF0 helped the design team to identify key inputs at each stage, and what information was to be passed between stages as pre-requisites (egg. the shoot command Page | 10


in A4) and feedback (e.g. from A3 to A2). The tool also defined clearly when the key input of ‘physical force’ was required to trigger the required functionality. Use of the IDEF0 led to further work in updating tools such as the Operational Description Template.

Fig. 9. Snippet of IDEF0 level 2

11. Decision Matrix Decision matrix as a tool provides an objective way for the design team to make critical decisions. On this project, this tool enabled the design team to select which animal species to use as an attachment for this transformer toy. Key factors such as appearance, size, cost to build and number of sharp edges were identified and then evaluated. This evaluation encompassed a variety of metrics, with the factors such as cost to build being directly measured, with appearance being graded on a 1-5 scale, and the same factor also focusing on the need for ‘human-centric’ design. An important point to note is that the values are normalized and then given weights based on user dependency to make sure that each factor is rated on its importance to the user. The two options with the highest scores were selected, the horse and the eagle attachment. Since the difference between the eagle and the tiger option was small, both options were then debated among the design team to further clarify on the decision matrix parameters, with ultimately the eagle version being selected. This tool then led to the design work of the final versions of the eagle and horse attachments, as well as defining the key interfaces between these attachments and the robot structural frame.

12. Goal Question Matrix (GQM) Measuring a system’s performance to ensure the customer’s needs is important. The GQM enables the design team to do exactly that by identifying the performance measurement goals Page | 11


and then generating questions that define these goals in a quantitative fashion. Each of these questions then refers to metrics, the ideal metric and the approximate metric, with the ideal metric being the preferred source of information. Mechanisms to collect data are also selected. A key point to note is that the GQM goals should allow the performance to be measured at different stages of the project, not only when the final prototype is ready. This can be seen in Figure 10 where metrics such as ‘make the toy affordable’ are identified early on in the design process and then measured using a survey of similarly functional toys available in the market. Identifying the goals of this transformer toy involved making sure that each of the goals had a clear singular target, and that the goal target was quantifiable (egg. hours of operation until toy breakdown – Figure 10). This tool helped analyze that there were four metrics which required the transformer toy to reach a completed prototype to even begin gathering data. Any feedback which generated design changes would then lead into delays in meeting production targets. Thus it was important to keep a calculated buffer in the project timeline to accommodate this. Use of the GQM also led to design work in the Analytical Hierarchy process which is talked about next. Goals

Question

Ideal Metric

Approximate Metric Data Collection Method Percentage of market population Market survey who can afford the toy

Make the toy affordable for parents

Is the toy affordable for most families?

Price of other similar toys

Make the toy reliable

How long till the next battery replacement?

Hours of operation till Days of operation till Direct measurement battery replacement battery replacement

How long until toy breaks?

Hours of operation till Days of operation till Direct measurement toy breakdown toy breakdown

Fig. 10. Sample entries from GQM

13. Analytical Hierarchy Process The analytical hierarchy process involves applying weights to the goals defined in the GQM tool. There is essentially a 1-to-1 ratio with the goals and the original toy objectives, and that’s because all goals were made with respect to just one system. This tool provided an insight into the relative priorities of each goal for the toy system, while at the same time enabling the design team to classify each goal in terms of the actors involved (e.g. the child, the parent, the pet), the attractiveness of the toy (e.g. making the toy stylish by using multiple colors and sounds) and the cost of the toy (which had a relatively modest weight of 0.030). These goals priorities are then compared to the priorities generated by the customer affinity process to ensure that the design team is on the right track. Use of this tool provided a key understanding that customer needs always need to be prioritized and that each function of the toy should be satisfying those customer needs in some way, else that function is just adding overhead in terms of cost and effort. Use of this tool led to a better draft of the CVP, which is discussed next.

Page | 12


Make the toy usable without supervision

Make the toy easy to carry

Make the toy easy to use 0.2

0.6

0.4

=0.2*0.6

=0.2*0.4 0.120

0.080

Fig. 11. Sample columns from the Analytical Hierarchy Process

14. Customer Value Proposition (CVP) The CVP is a tool used to communicate the product’s value to the organizations management. It matches the functional features of the product to specific customer needs, while at the same time also specifying which feature better matches a need than the product’s competitors. A snippet of the CVP of this transformer toy helps clarify these definitions.

“The toy comes with two attachments, the horse and the eagle, which attach to the front of the toy in vehicle mode, and attach as the toys legs in robot mode. These attachments address the customer’s needs of looks involving animals and the toy coming with different figures.” This tool again provides the design team with an emphasis on the toy meeting the customer’s needs. The CVP along with the analytical hierarchy process enabled the design team to match each of the toy’s goals to specific customer needs to ensure that no features were superfluous and that all the high priority needs were being satisfied.

15. Quality Functional Deployment (QFD) The analytical hierarchy process also provides input to the QFD. The QFD provides an indepth look into the impact of the system’s engineering characteristics on product objectives. The tool also provides a way to benchmark the system against its competitors. The QFD helps transform customer needs into engineering characteristics for a product, prioritizing each product characteristic while simultaneously setting development targets for the product. Page | 13


Use of the QFD provided an understanding into the positive impact of engineering characteristics such as ‘maximum projectile launch velocity’ on customer needs such as making the toy more fun, while at the same time evaluating the negative impact on customer needs such as toy safety. The relative importance of each customer need is highlighted in a separate column to evaluate the tradeoffs between these positive and negative impacts. The tool also provided a better comprehension of the relationships between the engineering characteristics (As can be seen in Figure 12). Competitors listed in appendix A.23 were then benchmarked against the transformer toy to ensure that the design was matching up evenly, or better in most customer needs (Figure 13). The bottom section of the QFD quantifies the engineering characteristic measures between the transformer toy and its competitors, providing accurate targets for the transformer toy to meet (Figure 14). This tool led improving the transformer toy’s tensile strength as this was found lacking in comparison with its competitors, fine tuning the projectile launch velocity to ensure a balance between the customer needs of fun and safety, and increasing the mean time to failure (MTTF) of the transformer toy system to make it more reliable. The tool also led to design rework in the analytical hierarchy process and the GQM.

Fig. 12. Relationships between engineering characteristics

Page | 14


Fig. 13. Rating the CARTER transformer toy with competitors (see Appendix. A.11 for more details)

Fig. 14. Objective measures and targets

16. Subsystem Definition and Allocation Working on the complete system at the same time provides more difficulty. A better approach is to ‘divide-and-conquer’. The system is split into multiple subsystems, with each providing either separate functionality or an easier design approach. Subsystem allocation refers to requirements – both behavioral and structural to the identified subsystems. An important development of this process is to identify the interfaces, i.e. the locations where these subsystems inter-connect, as most of the system failures occur at the interfaces. For this project, the toy subsystem was divided into seven subsystems as shown in Appendix A.12. The originating requirements, along with a selection of the concept fragments generated for those requirements, were then distributed among the subsystems. Important requirements such as safety were repeated in multiple subsystems of ‘electrical and sound’ and ‘projectile’, which further led to building separate and more targeted safety requirements for those subsystems. This work then led to identifying who as responsible for those subsystems, and thus provided a clear demarcation of responsibility. This tool also enabled multiple subsystem design to be worked on in parallel, thus reducing the length of the project timeline.

17. Operational Description Template The ODT is a key system engineering tool, providing insight into a multitude of project elements. The tool allows the user to review system use cases and requirements, map Page | 15


behaviors to subsystems, identify triggers and system states, extract functional requirements and trace derived requirements to originating requirements. Use of this tool on the project allowed the design team to better understand the interaction between the various subsystems at their interfaces, clearly identifying what are the triggers and responses, and to set quantitative targets for these. While building the ODT document, the design team was able to extract many derived requirements, which were later mapped to originating requirements, thus signifying the mapping of these derived requirements to the customer’s needs. The design team was also able to fine tune the timing targets for each of the operations to ensure the toy’s proper functionality. The ODT being a large document, is accommodated in Appendix. A.13, while a snippet showing the interaction between two subsystems is detailed in Figure 25.

Fig. 15. Snippet of ODT showing interface rows (grey)

18. State Diagram and Matrix The State diagram specifies the different states the system can be in, and any triggers which would cause the system to change its state. The states can specify different modes of operation, and the triggers could either be different external conditions, or different set of performance rules. The state diagram for this project is listed in Appendix B.10, with a snippet available in Fig. 16. Use of this tool allowed the design team to better understand all possible states the system could be in, and if any of those states were undesirable (either from a functional or safety perspective), reduce or eliminate the probability of the system reaching that state. These decisions were defined using event and fault trees (detailed later) to quantitatively verify the toy’s functionality.

Page | 16


Fig. 16. Different states (in this case modes of operation) of the CARTER transformer toy

19. Interface Matrix The interface matrix provides an in-depth look into the interactions between specific subsystems, providing quantifiable inputs and outputs. The identification of the interface champion helps ensure the responsibility of that interface, as well as providing a contact who specializes in those subsystems design. These quantifiable values are either directly mentioned, or a location to their documentation is explicitly referenced. Using this tool, key inputs and outputs between the transformer toy’s subsystems of attachment and the other subsystems were identified (as shown in Figure 17). This matrix provided a comprehensive detail of the attachment subsystem to the other subsystems, providing a central point for any design team member looking for information on a specific subsystem interaction. Use of this tool led to further design work in identifying key data which was earlier missing (such as connection pin diagrams) but was later incorporated into the toy’s design.

Fig. 17. Sample Interface matrix entries

20. Behavioral Test Plan A smart professor once said ‘Test Early and Test Often’. This is the main ideology behind building comprehensive testing strategies. This section will talk about behavioral testing, while the next one talks about non-behavioral testing. A good test should enable the design team to make a decision on what direction to take next. IF this direction is not clear at the Page | 17


end of the test, additional follow on tests must be created to make the course of action clear. The behavioral test plan looks at the performance of the product in conjunction with its required functionality. Another important point of note is that testing should be done as early as possible, not waiting for the complete product to be ready before testing. Using the behavioral test plan helped identify key exit conditions for the transformer toy or its subsystems to be considered a success. Failure in the test plan (such as being waterproof) required the design team to go back and figure out a more suitable casing for the power subsystem. The behavioral test plan also provided an insight into both the intentional and unintentional functionality of the transformer toy (such as in Figure 18). Test Facilities

7 year-old child

Entry Condition Completed structural prototype

Exit Condition 7 year-old child is able to arrange the toy in various poses. The toy should be able to balance on a flat surface with each pose

Fig. 18. Sample behavioral test plans

21. Non-behavioral Test Plan Non-behavioral test plans incorporate various verification methodologies (Analysis, Inspection, Demonstration and Physical test) and are mostly used to verify the engineering characteristics as defined in the QFD. Again, the focus should be on being able to test different subsystems, or different components of a subsystem separately to ensure that work can be done in parallel. Rigorous testing of the interfaces is needed, as again most of the systems fail at their subsystem interfaces. Non-behavioral test plan was built for the transformer toy, and it provided an understanding into the values used as the targets in the QFD (toy velocity, projectile velocity). This tool also helped better define these engineering characteristics, and thus provide feedback into updating the QFD. This tool, along with the behavioral test plan led to building the VCRM matrix, which is talked about next. Test # TP.8

Test Method Measure dist. thrown of designed projectile. Derive launch vel. from analysis neglecting air resistance.

Verification Method (AIDT) D

Test Facilities Flat surface, stopwatch, measuring tape, launch target

Entry Condition

Exit Condition

Integration of projectile Derived velocity is within 2 subsystem with structural body standard deviations of value subsystem calculated from design

Fig. 19. Sample non-behavioral test plan

22. Verification Cross Reference Matrix (VCRM) The VCRM links the test methodologies developed (both behavioral and non-behavioral) to the originating requirements developed. Using the VCRM provided an understanding into how the testing procedures for the transformer toy and its components link back to the originating requirements, which again link back to the customer needs. Thus the design team was able to rework on the test Page | 18


procedures again by keeping the customer needs as top priority. The tool also acts as sort of checklist to ensure that once tests were successful, the design team could objectively put forward that the corresponding customer need had been met.

23. Failure Modes and Effect Analysis (FMEA) The FMEA is used to identify all possible failure modes of not only each subsystem, but also of the system as a whole. The FMEA also details the potential impacts of each of these failure modes, and suggests corrective actions to resolve said failure modes, thus acting as a risk estimation technique. Each failure modes severity and occurrence rating is also determined (these are talked about later) to give a quantitative value to the potential impact of each failure mode. These failure modes could be due to any of the MMMME reasons (Man, Machine, Method, Material, and Environment). Use of this tool on this project enabled the design team to identify key failure modes of the transformer toy subsystem, viz. the electrical system not being able to ground the leakage current, thus proving to be a safety hazard for the user. Multiple corrective actions were then suggested by the design team, and using another previously mentioned tool, the Decision Matrix, the solution to minimize this failure mode was determined. The final action was to house each electrical unit, as well as any connections in a special polypropylene04 material to make sure that such a failure mode had an occurrence of less than 50 times the user’s required time for the product. Failure Mode Number

F.1

Identification of Item or Failure Mode Function Projectile Launch System Failure to Launch

Failure Effects (a. Local b. System c. Mission)

Possible Causes

b. Projectile not launched or launched late Broken launch spring, broken c. Failed or degraded crossbar

Corrective Action (a. design b. manufacturing process c. operation) a. Use more durable spring material, use stronger crossbar material

Fig. 20. Sample FMEA entry

24. Severity Rating System and Occurrence Rating System As discussed in the previous section, the severity rating system enables the design team to quantifiably rank the severities for the product’s failure modes. It helps define whether the potential impact will be easy or difficult for the users to overcome. As can be seen in Figure 21, a severity level of 1 also assists in determining the tolerance levels of the system’s performance. The severity rating system for this project also gives a ‘minor’ severity rating to any potential manufacturing process variations. This tool also enabled the team to build most of the toy structure to be repairable by any able adult (usually the child’s parents or even older siblings).

Page | 19


Severity 1 2 3 4 5 6 7

Description None Minor Low Moderate High Critical Hazardous

Explanation Variation within performance limits Variation correctible during production Reparable by user within 10 minutes Reparable by user within 1 hour Repairable only by service technician Not worth repair, degraded functionality failure Affects safety of operator with no advance warning

Fig. 21. Severity rating system The occurrence rating system on the other hand helps identify the persistence of any of the available failure modes. As can be seen from Figure 22, a mean time between failures (MTBF) equal to the toy’s expected lifecycle gets an occurrence rating of 5, which is still considered exceptionally high. Most of the toy’s target failure modes is to have an occurrence rating of 5 to 10 times the toy’s expected lifecycle. Use of these two tools, along with the FMEA allowed the design team to focus on the durability and robustness of the transformer toy’s design, again satisfying these two critical customer needs.

Occurrence 1 2 3 4 5 6 7

Description MTBF is 50 times greater than user's required time MTBF is 25 times greater than user's required time MTBF is 10 times greater than user's required time MTBF is 5 times greater than user's required time MTBF is equal to user's required time MTBF is 25% of user's required time MTBF is 5% of user's required time Fig. 22. Occurrence rating system

25. Risk Priority Number Table, Criticality Rating System, Stoplight Graph The Risk priority number is defined as the product of the severity and occurrence for a particular failure mode. The higher the risk priority number, the more importance need to be given to that failure mode to ensure that corrective actions are taken before moving ahead. The criticality table (also known as the RPN table) defines all possible values of the criticality (as shown in Appendix A.20), with the spotlight graph depicting the distribution for the current failure modes. Using these tools on the CARTER transformer project allowed the design team to minimize the number of failure modes that lay in the very high (Red section, as shown in Figure 23) of the spotlight graph, and further making sure that not only was a corrective action in place, but multiple fallback procedures were in place as well if the corrective action did not resolve Page | 20


Severity

the failure mode. Use of these tools led to a better understanding of the FMEA matrix developed in the previous section, while at the same time these tools provided an updated FMEA matrix of said system.

7 6 5 4 3 2 1

1

1

1 1 2

1 1 2 3 4 Likelihood

5

6

7

Fig. 23. Spotlight graph

26. Event Trees and Fault Trees An event tree helps analyze a series of events using Boolean logic, with the sequence progressing in either a bottom-up or top-down approach. A fault tree on the other hand provides a similar approach to deducing failure analysis of the current state of the system. Both of these tools serve as inputs to risk management techniques in deciding how to overcome said failure modes. In most cases, a fault tree works from the undesirable end event to the causes, usually in the direction opposite of time, while an event tree works forward in time, from the cause to the undesirable events. On this project, an event tree was developed to identify potential causes of the failure mode ‘no sound from toy’ (Figure 24). This tool enabled to identify and list all possible causes, either separately, or in conjunction, which caused this failure mode to occur. This then led to the design team focusing on increasing the reliability of the speaker system, while at the same time focus on improving the efficiency of the power subsystem (to ensure that the batteries last longer).

Page | 21


Fig. 24. Snippet of event tree for event – “No sound from toy”

27. SysML Parametric Diagram Parametric diagrams are commonly used to indicate relationships between different variables, and the outcomes that they produce. The constraint blocks specify mathematical formulae to illustrate these relationships. For this project, parametric diagrams were used to calculate the maximum sound intensity for the transformer toy’s sound levels. They then enabled the design team to tune this value based on customer requirements and the safety regulations for toy’s target age group.

Fig. 25. Parametric diagram to calculate sound intensity

28. Timeline The project timeline lists tasks specific to the project in a chronological order. It also depicts estimates for these tasks, an estimate of time needed to perform each task, as well as if any special resources are required. Appendix A.22 gives details of the CARTER transformer toy project timeline, with a snippet visible in Fig. 26.

Page | 22


Use of this tool on this project allowed the design team to better understand the project as a whole, with being able to identify any key dependencies between tasks, and any cases where execution could be carried out in parallel. Another benefit provided by this tool was that it was easy to book any special resources in advance, and schedule certain tasks around these special resources’ availability. This tool helped better define the location of each testing procedure for the system and the subsystems. Going forward, the toy development can continue from a marketing perspective, now that the engineering design is completed. Deliverables such as marketing campaign documentation, vendor selection RFPs and distribution strategies can be prepared.

Fig. 26. Snippet from CARTER Transformer timeline

Page | 23


References 1. Engineering Complex Systems with Models and Objects by D. Oliver, T. P. Kelliher, and J.G. Keegan, Jr. (McGraw-Hill. 1997). 2. www.nasa.gov 3. www.ibm.com – Behavioral modeling in SysML

Page | 24

Ms2788 hasbro carter report  
Ms2788 hasbro carter report  
Advertisement