A Signal Grammar to Guide Functional Modeling of Electromechanical Products

Transcription

1 Robert L. Nagel Jayson P. Vucovich Robert B. Stone Daniel A. McAdams Design Engineering Laboratory, University of Missouri Rolla, Rolla, MO A Signal Grammar to Guide Functional Modeling of Electromechanical Products In modern product design methodologies, designers are increasingly required to combine elements spanning multiple engineering domains, thus blurring the boundaries between engineering disciplines. Functional modeling with the Functional Basis provides the basic tools required to integrate system models at the conceptual level; however, there is a lack of unified rules to address the structure of functional models. This article covers the development of a grammar for functional modeling with a Functional Basis. At the conceptual level, flows represent the information vital to a proper system operation. Signal flows are explored through their Functional Basis lexicon and primary/ carrier flow relationships. A grammar, consisting of morphology and syntax, is presented and applied to a set of electromechanical, component-based building block examples. To further demonstrate the application of s in functional modeling, an electromechanical product is explored functionally with the application of the grammar. DOI: / Introduction Contributed by the Design Theory and Methodology Committee of AS for publication in the JOURNAL OF CHANICAL DESIGN. Manuscript received December 14, 2006; final manuscript received May 14, 2007; published online March 25, Review conducted by Yan Jin. Electromechanical design often requires designers to create an engineering solution that spans multiple engineering domains. Often, this forces engineers to synergistically consider design elements from numerous engineering fields such as mechanical, electrical, and computer. For successful designs to emerge, the integration of engineering domains must be considered through all phases of product design, both conceptual and physical. Design elements must work together flawlessly, requiring adequate communication, monitoring, processing, and decision-making abilities. The modeling of information, i.e., flow, is vital for accurate and complete design models that support the design process. One approach to developing system models to support multidisciplinary engineering projects and products is functional modeling. A functional model is a description of a product or process in terms of the elementary functions that are required to achieve its overall purpose 1. A function is an operation by a device or artifact on a flow of material, energy, or passing through the device or artifact. While the concept of defining product function as a step in the early phases of product design has existed in the literature since at least the mid-19th century 2 4, it still lacks the formalization of other accepted engineering design analysis techniques. At the same time, however, functional modeling offers significant capabilities for product design in several areas 1. Systematic methods to model product functionality. Functionality is arguably one of the fundamental constructs of product design. The ability to model a product s functionality independent of and prior to form is critical for products that meet customer demands. Creativity in concept generation. The ability to decompose a complicated task into simpler pieces is a critical step in the synthesis process 5. Identifying the key functionality of a product to be designed significantly increases the ability of designers to break problems down and find innovative solutions. Archival and reuse of design knowledge. Products are transient, and the design process and decisions that led to the product are even more fleeting. A functional model provides a record of the abstract requirements of the embodied product. Recording the relationship between function and product components allows future designs to leverage the past knowledge of previous designs and designers. Product architecture definition. The functionality of a product, arranged graphically as a functional model, can guide the architecture of a product. Groups of functions operating on common flows the connections between the functions lead to modules or platforms on which a family of products may be designed. Accepting the premise that functional modeling is an important step in a product design process, the general approach to functional modeling provides the graphical tools required to develop a complete model of a product during conceptual design. When the Functional Basis is used for terminology, there is consistency of nomenclature that allows for a universal understanding of function and flow 6. The Functional Basis, however, does not explicitly address consistency of model structure. Structure must be provided through a well-defined grammar consisting of morphology and syntax. Without a properly defined grammar, difficulty arises in the development of uniform and synergistic models that completely and accurately represent all engineering domains. Material and energy flows have an established grammar built from trial and error conventions 7,8. Signal flows, however, tend to be much more ambiguous. An anecdotal study by the authors of 20 electromechanical products that were dissected and modeled functionally with the Functional Basis revealed vastly different techniques on how flows were modeled. Thus, there still exists the possibility for flows and functions to be incorrectly used, leading to modeling errors. To overcome this deficiency, a grammar consisting of morphology and syntax is needed to provide structure to functional modeling with the Functional Basis. In its current form, the Functional Basis is best thought of as a lexicon, requiring the structure of grammar for consistent usage. From linguistics, we can find the following definitions for lexicon, morphology, syntax, and grammar Lexicon: the vocabulary of a language; the complete set of meaningful units in a language. Journal of Design Copyright 2008 by AS MAY 2008, Vol. 130 / Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

2 Morphology: the sum of the relationships defining the combinations of the smallest meaningful units of a language. The smallest meaningful units of a language are called morphemes. Syntax: the arrangement of words and phrases to create well-formed sentences in a language. Grammar: the whole system and structure of a language or of languages, in general, usually taken as consisting of syntax and morphology and sometimes also phonology and semantics. Modifying the above definitions to the domain of functional modeling, we define functional lexicon, morphology, syntax, and grammar as follows. Functional lexicon: the entire set of function and flow terminology that makes up the Functional Basis. Functional morphology: the arrangement of function and flow terms into function-flow pairs. Functional syntax: the overall arrangement of function and flow pairs into well-formed function chains and aggregated functional models describing a product, system, or artifact. Functional grammar: the whole system and structure of the Functional Basis consisting of functional morphology and functional syntax in the form of modeling templates. This paper develops a grammar consisting of a set of morphology rules and a set of syntax rules to increase the consistency of flow usage in functional modeling. Signals are defined in Sec. 3, and their Functional Basis lexicon is presented. The grammar consisting of morphology and syntax is formulated in Sec. 4. In Sec. 5, the grammar is then applied to a series of building block examples to show how they might be transformed and applied as functional modeling templates, and through an example of electromechanical product, the integration of flows into an overall functional model is presented. 2 Prior Work The technique of functional modeling allows a product designer to graphically represent both function and flow in an early design and can be found in many texts on engineering design methodologies 3,5, When functional modeling is performed with the Functional Basis, product designers have at their disposal terminology for function and flow terms where functions take the form of action verbs and flows take the form of nouns 1,6. The complete taxonomy of terms provided by the Functional Basis can be found in Ref. 6. The Functional Basis in its current form is a refinement of past ideas and works to develop a language of functional modeling. Pahl and Beitz presented the idea of a functional basis for product decomposition with material, energy, and flows 3. Hundal presented a further refined set of function and flow classes 15 ; however, this work lacks a separate function category for s and is further refined by Little et al. with the Functional Basis Set 19. Stone and Wood then presented the Functional Basis as a design language of function and flow terms with precise definitions 1. The Functional Basis is then reconciled into its current form by Hirtz et al. 6. Functional modeling with a Functional Basis has spawned research into a wide array of product design applications that would benefit from functional syntax and grammar. Functional modeling techniques using the Functional Basis are being applied to concept generation, design knowledge storage and reuse, early risk analysis, cost optimization, component reuse, and conceptual design visualization Functional modeling with a functional basis is also being applied to modeling processes, events, and human-product interactions 38,39. A functional syntax and a set of functional grammars will promote a more consistent design synergy between each of these areas of design research. In an effort to standardize the assembly of functional models and to shorten the learning curve, Sridharan and Campbell put forth grammar rules in the form of function structures 7,8. The grammar rules are based on products dissected and modeled with the reconciled Functional Basis and are archived in the University of Missouri-Rolla UMR Product Design Repository. The grammar rules are meant to capture all possible flows between function structures. Some problems with their grammar rules are that their rules were only established for energy and material flows due to an inherent ambiguity of flows that Sridharan and Campbell attributed to environmental unknowns. Because flows were omitted from their grammar, it becomes difficult to fully utilize the function grammar set to generate an accurate functional model integrating multiple engineering domains. In an electromechanical design, s are vital to establish the synergy among engineering domains. Increased recognition of the need for an integrated design among engineering disciplines through the acceptance of fields such as mechatronics has increased the need for a clarified methodology to systematically represent system level flows in functional models. At the heart of many mechatronic systems lies a control scheme based on system sensory data, requiring comprehensive integration of sensors and actuators. Traditionally, control systems are modeled via a block diagram, where individual blocks represent an element of either the controller or the system and are connected with lines representing the flow of information 40. Blocks are typically labeled to denote what dynamics they represent and contain a transfer function modeling the dynamic response of the system element. Block diagrams fall short in aiding the overall system design due to a failure to functionally represent all component interactions, whether through, energy, or material flows. In an effort to model control systems at a design level, Chen and Törngren researched the functional requirements of control systems, giving primary focus to informational flow either data, control, or mixed and its characteristics as applicable in a control system 41. The research of Chen and co-workers established a functional modeling methodology for mechatronic systems that tries to fill the void in typical control system modeling techniques and to bridge the gap between functional modeling of control systems and all other noncontrol based product interactions 42,43. These methods, however, do not present a methodology to integrate system interactions not requiring direct control into their model. Rajan 44 and Rajan 45 applied functional modeling to control systems by developing a four-step methodology for modeling control systems based on the reconciled Functional Basis. Their work looks at the development of the model for the controller and its associated input transducers. Through modeling a wide array of input transducers, Rajan et al. established a modeling methodology to model the transmitted and energy flows within each transducer. Their research, however, considers the and energy flows separately, not making the connection that energy is the carrier of the flow. The models contain knowledge that is useful for product dissection and failure analysis but are far more detailed than can be achieved during the functional stages of conceptual design. 3 Signal Lexicon The reconciled Functional Basis by Hirtz et al. 6 establishes a set of definitions, which hold in them the guidelines governing how functions and flows should interact. This function and flow terminology for s constitutes a lexicon for representation. In the following subsections, the as a functional modeling flow is defined, and a lexicon, as defined by the Functional Basis, is provided. 3.1 Signal Defined. What is a flow? A is typically defined as information about a system or its surroundings. In / Vol. 130, MAY 2008 Transactions of the AS Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

3 primary carrier Fig. 1 Function Primary primary carrier Function Primary primary carrier Function Primary primary carrier Function blocks illustrating primary and carrier flows Ref. 17, flows are defined as information for the internal decision-making capability of a device or sensory data provided to or by a device or process. Stone and Wood further defined a by clarifying that a is either a material or an energy flow with the specialized purpose of carrying information 1. A, while being its own class, is actually a subset of either energy or material. All s are some form of energy or material, but not all energies and materials are s. This is due to the very nature of a. Since flows are information that will enter into, out of, or travel through a system, they require a carrier of sorts. A mailbox flag is an example of a material energy carrier where the flag carries the discrete control to pick up mail. Often, it is important during the design phase to represent the flow carrier relationship. This relationship is represented using primary/carrier flow properties. Primary/carrier flow properties, shown in Fig. 1, allow the designer to represent a primary flow required to meet the input/output requirements of the black box model and its supporting carrier flow that aids the primary flow in the completion of its black box requirements. A primary flow, being of principle influence to the system, is described by each function block that it passes through. Primary/ carrier flow properties are typically consistent across function chains; however, there are times when it may be necessary to represent changed functionality of a flow that in a prior block was represented by a carrier. Typically, this occurs when the carrier flow changes its form. Due to this ability for a primary/carrier property to change, it can be said that primary flow properties are independent of the function chain. From the mailbox example, the material flow mailbox flag is the carrier flow and the is again the primary flow. 3.2 Lexicon. A, at the primary level of the Functional Basis, is a flow with the purpose of providing vital system data. The Functional Basis clearly defines flows at the secondary and tertiary levels 6. Signal flows are defined at the secondary level as being one of two separate flow types, status or control, which are then further defined at the tertiary level. At this tertiary level, status can be auditory, olfactory, tactile, taste, or visual, while a control can either be analog or discrete. These flows are defined below 6. Signal : a condition of some system, as in information about the state of the system Auditory: a condition of some system as displayed by a sound Olfactory: a condition of some system as related by the sense of smell or particulate count Tactile: a condition of some system as perceived by touch or direct contact Taste: a condition of some dissolved substance as perceived by the sense of taste Visual: a condition of some system as displayed by some image : a command sent to an instrument or apparatus to regulate a mechanism Analog: a control sent by direct, continuous, measurable, variable physical quantities Discrete: a control sent by separate, distinct, unrelated, or discontinuous quantities 3.3 Function Lexicon. The reconciled Functional Basis provides a set of functions that act on, with, or in response to flows. From the Functional Basis, there are two functions, actuate and regulate, defined below, requiring the input of a to control the magnitude of another flow in a separate flow chain 6. : to commence the flow of energy,, or material in response to an imported control Regulate: to adjust the flow of energy,, or material in response to a control such as a characteristic of flow The Functional Basis also provides a set of functions defined to output flows representing system information in response to another flow. These flows, under the primary function class of, are defined to ascertain and provide vital system information back into the system or to the user. System information is provided in the form of a flow. The functions and their definitions are provided below 6. Signal: to provide information on a material, energy, or flow as an output flow : to perceive or become aware of a flow Detect: to discover information about a flow Measure: to determine the magnitude of a flow : to make something known to the user about a flow Track: to observe and record data from a flow Display: to reveal something about a flow to the mind or eye : to submit information to a particular treatment or method having a set number of operations or steps. There is also a set of function terms in the Functional Basis that are defined to take in or put out control s as well as other flows from a system. These terms, under the primary function class channel, are import and export and are commonly used when the system emits a control outside of its boundary to be received either by another system or by itself. The import and export function terms are defined below 6. : to bring in a flow material, energy, from outside the system boundary : to send a flow material, energy, outside the system boundary Finally, the function convert also operates on control s and can transform their state. The control function term is defined below 6, : to change from one form of a flow material, energy, to another. For completeness, any type of flow conversion is valid. 4 Signal Grammar A grammar has been enumerated from functional models modeled with the Functional Basis for both energy and material flows 7,8 ; however, s, while also having inherent Functional Basis guidelines, have no previously established usage grammar. In the following subsections, a grammar based on the Functional Basis for function and flow terminology is presented. The grammar consists of morphology guiding the interconnectivity of function and flow terms and syntax providing functional modeling templates. The developed grammar provides a structure Journal of Design MAY 2008, Vol. 130 / Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

4 Rule 3 primary flow () carrier flow (material or energy) Signal Rule 4 Rule 5 Rule 6 discrete control flow of interest Reaction to Optional User Indicator (Rules 7&9) analog control Regulate flow of interest (energy, material or ) Rule 7 Rule 8 Rule 9 status Fig. 3 Actuator syntax rule status status Signal however, respective entering flows must also exit. Rule 10 Rule 11 Rule 12 control Fig. 2 control Signal and templates to aid in the manual and automatic assembly of functional models and guides the assembly of subfunctions, utilizing nodes to clearly establish the location of system boundaries and the required input and output flows. 4.1 Signal Morphology. The following 11 rules have been derived from the definitions provided by the Functional Basis and constitute the morphology for flows. Signal morphology guides the arrangement of related function and flow terms through a functional model and is meant to clarify how and when flows are to be applied in electromechanical products. To aid in the visualization of the morphology, Rules 3 12 are illustrated in Fig. 2. Rule 1: Use status s to provide information on auditory, olfactory, tactile, taste, or visual states of the system. Rule 2: Use control s to send an analog or discrete operational command to an instrument or apparatus. Rule 3: Use a primary flow to denote a and a carrier flow to denote its energy or material carrier. Rule 4: Use the actuate function to discretely toggle a flow material,, energy. functions require a discrete control to toggle state. Rule 5: Use the regulate function to adjust a flow quantity material,, energy in an analog manner. Regulate functions require an analog control to adjust flow quantity. Rule 6: Use the sense function to detect or measure a flow material,, energy. functions require an input of the flow of interest to output a status representing data collected. Rule 7: Use the indicate function to provide system status to the user. functions end flow paths; thus, status flows exiting an indicate function block leave the system and do not connect to other function blocks. functions do not receive a carrier flow. Rule 8: Use the process function to execute a series of operations to extract conditional information on a flow. Either control or status flows can enter process functions; Signal flow morphology rules Rule 9: Use the convert function to perform the conscience act of changing a flow s type. A status flow input to the convert function should output as a system-usable control. A control flow input to the convert function should output as a status flow. Rule 10: Use the import function to bring a control flow from the outside of the system boundary to the inside of the system boundary. arrows should be drawn into an input function block to represent flow into the system. Rule 11: Use the export function to send a flow outside of the system boundary. arrows should be drawn leaving the export function to represent control flowing from the system. Rule 12: Use the transfer function to move a flow through a system. Either control or status flows can enter transfer functions; however, respective entering flows must also exit. 4.2 Signal Syntax. The previously presented morphology rules are used to build syntax for s. The syntax manifests itself as functional modeling templates that can be modified and inserted into a functional model, aiding in the manual or automatic assembly of functional models, thus increasing the accuracy of product and design representation. Each syntax rule is explained and visually represented in the following subsections Actuator. An actuator, shown in Fig. 3, is a discrete control device used to turn another flow on or off. In a conceptual design, if it is known that a flow will be toggled, an actuator should be implemented. To functionally build an actuator, the actuate function must be used in conjunction with Rules 3 and 4. A control, its carrier, and the flow to be toggled should be imported with import function-flow blocks, as shown to the left of the functional requirement arrow in Fig. 3. Then, following Rule 12, a transfer control function-flow block represents the routing of the control to an actuate flow function-flow block. Optionally, the actuator can indicate its status. To indicate the status, Rule 9 is followed to convert the control to a status and Rule 7 is followed to indicate the status through an indicate status function-flow block Regulator. A regulator, shown in Fig. 4, is an analog control device to adjust a flow in a variable manner. When it is known in a conceptual design that a flow is to be adjusted in a variable manner, a regulator should be implemented. To functionally build a regulator, the regulate term must be used in conjunction with Rules 3 and 5. To implement a regulator, a control, its carrier, and the flow to be adjusted should be imported with import function-flow blocks, as shown to the left of the functional requirement arrow in Fig. 4. The control and its / Vol. 130, MAY 2008 Transactions of the AS Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

5 to Reaction Optional User Indicator (Rules 7&9) Regulate Fig. 4 Regulator syntax rule to carrier are routed to the regulate flow function-flow block via a transfer control function-flow block following Rule 12. If the regulator indicates its status, Rule 9 is followed to convert the control to a status with a convert control to status functionflow block, and Rule 7 is followed to indicate status Sensor. A sensor, shown in Fig. 5, is a device used to detect or measure a flow and then output a representing collected information. Sensors would be used during conceptual design if a designer realizes that a design must ascertain information about itself or its surroundings. To functionally build a sensor, the sense term must be used in conjunction with Rules 3 and 6. To implement a sensor, transfer a flow material, energy, or to a sense flow function-flow block. The sense flow function-flow block outputs primary status flow and its respective carrier flow, which can then be transferred with a transfer status function-flow block by Rule 12. The final destination of the status flow and carrier can be the system, the user, or both. The sense function can be further detailed at the tertiary level by the reconciled Functional Basis with its tertiary functions detect and measure. The general sensor functional model, shown in Fig. 5, can modified to reflect the increased detail of tertiary terms by using one of the two tertiary terms in place of the sense function Indicator. An indicator, shown in Fig. 6, is any device with the goal of providing vital system information to the user. A designer might use an indicator during a conceptual design when it is known that some form of feedback is required from the system. To functionally build an indicator, the indicate term must be used in conjunction with Rule 7. To implement an indicator, run a status flow from the function-flow block from which system information should be obtained. An indicator is the exception to the primary/carrier rule Rule 3 since it can be as simple as the operation of the system or as complex as a series of components Material, Energy, or Signal Fig. 5 Sensor syntax rule Fig. 7 or syntax rule providing full diagnostics on system behaviors; in either case, however, an indicator is not required to send the outside of the system boundary. An indicate status function-flow block ends a flow path Rule 7, thus the status flow that exits an indicate status should not enter another function block. As with the sense function, the indicate function can be further detailed at the tertiary level by the reconciled Functional Basis with its tertiary functions track and display. The general indicator functional model, shown in Fig. 6, can be modified to reflect the increased detail of tertiary terms by using one of the two tertiary terms in place of the indicate function or. A processor, shown in Fig. 7, is any device that analyzes a status obtained from a sensor that has ascertained information, either internal or external to the system. Following analysis, the processor sends control information to system elements. A processor might be used during a conceptual design if a designer knows that the product will need to analyze the state on a series of conditions and make decisions based on the analysis. To functionally build a processor, the process term must be used in conjunction with Rules 3 and 8. To use a processor, run a primary status flow and a carrier flow into a process status function-flow block. Following Rule 9, to get a system usable control, connect the process status function-flow block to a convert status to control function-flow block with another primary status flow and carrier flow pair. Then connect the convert status to control to a transfer control function-flow block with a primary control and carrier flow. By the application of Rule 12, the control and its carrier flow is routed via a transfer control function-flow block to the controlled system elements Receiver. A receiver, shown in Fig. 8, is used to bring a control into the system. To functionally build a receiver, the import term must be used in conjunction with Rules 3, 10, and 12. To implement a receiver, a new control flow and its respective carrier must be imported into the system and thus cross the system boundary, as shown to the left of the functional requirement arrow in Fig. 8. The primary and carrier flows are then routed into the overall system by tying the import control function-flow block to a transfer control block Emitter. An emitter, shown in Fig. 9, is used to send a control from the system. To functionally build an emitter, the export term must be used in conjunction with Rules 3, 11, and 12. To implement an emitter, run a control flow and its carrier flow through a transfer control function-flow block. Then, tie the control and its carrier to an export control function- Function Fig. 6 Indicator syntax rule Fig. 8 Receiver syntax rule Journal of Design MAY 2008, Vol. 130 / Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

6 Fig. 9 Emitter syntax rule flow block. From the export control function-flow block, draw an exiting control flow and its carrier to represent them leaving the system boundary. Liquid CS () Valve Liquid to Regulate Liquid (reaction force) Liquid Liquid 5 Application As an application of the usage grammar, consider the following building block examples representing five basic types of control systems. Following that, a complete example of a more complicated electromechanical product is presented. 5.1 Building Block Examples. The following building block examples investigate the aforementioned flow syntax: actuator, regulator, sensor, indicator, processor, receiver, and emitter. The syntax is matched to individual components to show how they might be applied to represent an actual engineered system Switch. A switch is a mechanical device based on the actuator syntax. It is designed to either initiate or terminate a flow based on one of its two discrete states. Provided in Fig. 10 is a sample functional model of a switch. The operation of the switch requires imported mechanical energy to change the switch state. By Rule 3 for primary and carrier flows, mechanical energy is represented as the carrier flow used to set the switch state. By Rule 4 for actuate functions, a discrete control, carried by the mechanical energy, is used to actuate the electrical energy flow. It is important to note that the mechanical energy used to set the switch state is separate from the electrical energy that will pass through the switch. For user feedback, Rule 9 for convert functions is applied to convert the control to a status, and the indicator syntax is applied via morphology Rule 7 for indicate functions Valve. A valve is a mechanical device based on the regulator syntax. It is designed to adjust a flow in a variable manner. Provided in Fig. 11 is a sample functional model of a valve. The operation of the valve requires mechanical energy to be imparted on the valve to regulate flow. By Rule 3 for primary and carrier flows, mechanical energy is functionally represented as the carrier used to perform the work required to regulate the flow. Following Rule 5 for regulate functions, a control flow, carried by the mechanical energy, is used to set the flow rate. The control is converted to a status following Rule 9, and an indicator syntax is applied via Rule 7 for indicate functions to provide user feedback Transistor. A transistor is an electrical device based on the regulator syntax and Rule 5. It is used in electronic devices to adjust the flow of electrical energy. Provided in Fig. 12 is a sample functional model of a transistor. Transistors do not inherently provide user feedback; thus, the sample functional model in Fig. 12 does not include the optional indicator syntax. The operation of a transistor is controlled though an applied voltage electrical energy to the transistor s base, which allows a current electrical energy to pass. The voltage is a /energy executor whose applied value changes the current flow by altering the transistor s configuration. The relationship between the flow and the electrical energy carrier is represented functionally by following Rule 3 for primary and carrier flows. In a perfect transistor, there would be no interaction between the /energy executor voltage and the electrical energy current whose flow is being controlled Thermostat/or. A thermostat is based on the sensor syntax and follows Rule 6. It is designed to detect or measure thermal energy and provide a primary status carried by an electrical energy flow. Provided in Fig. 13 is a sample functional model of a thermostat transferring system information into a functional model of a processor. The processor is based on the processor syntax following Rule 8. The processor analyzes the status obtained from the thermostat, converts the status to a control, and transfers the control to the system. The control transferred into the regulator system the four functions operating on the flow of electrical energy is carried by an electrical energy flow that is used to regulate the flow of electrical energy in the example. The regulator system is Fig. 11 Fig. 12 Valve schematic and functional model Regulate Transistor CS () Energy Transistor schematic and functional model Switch Energy CS () to (reaction force) TE Thermal E TE Thermal E to Regulate Thermostat Energy CS (TE) o t Fig. 10 Switch schematic and functional model Fig. 13 Thermostat/processor schematic and functional model / Vol. 130, MAY 2008 Transactions of the AS Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

7 IR Emitter EM EM IR Detector EM EM Surface, Human Human, Sound, Motion, On/Off, Manual Operation Simulate Dog (Barking, Kicking, Digging) Surface, Human, On/Off Visible Reaction IR Emitter/Detector CS () Fig. 14 CS (EM) Energy IR emitter/detector schematic and functional model built following the regulator syntax and Rule 5 for regulate functions IR Emitter/Detector. An IR emitter is based on the emitter syntax which follows Rule 11 for export functions. Its purpose is to export a control carried by an electromagnetic energy flow outside of the system. An IR detector is based on the receiver syntax, which follows Rule 10 for import functions. An IR detector s purpose is to import a control carried by electromagnetic energy into the system. Provided in Fig. 14 are sample functional models of both an IR emitter and an IR detector. The IR emitter sends an electromagnetic energy, which, by Rule 3, carries a discrete control. The control is detected by the IR detector, which acts as a switch where the /energy executor is an electromagnetic control mix that actuates an electrical energy flow. The electromagnetic energy is converted to electrical energy and applied to the transistor, thus activating the current flow through the transistor. In the example, the emitter and receiver syntaxes are used in conjunction with an actuator syntax to actuate an electrical energy flow in a system. 5.2 Electromechanical Product Example: Digger Dog. The electromechanical dog simulator, Digger Dog, has been dissected and modeled functionally following the three-step functional modeling procedure outlined by Stone and Wood 1. Digger Dog, shown in Fig. 15, uses one of three input options to start a series of events kicking, barking, and tail wagging to simulate a dog digging a hole in the yard 46. As such, the Digger Dog product is a -rich environment in which to test the grammars. Audio and motion sensors allow for a level of automation where a Digger Dog senses ambient sounds and motion to automatically start its simulation events. A third input option is a manual tryme button that, when pressed, starts the simulation events. When not in operation, a Digger Dog sits idle waiting for a control. Fig. 16 Digger Dog black box model Step 1: Generate Black Box Model. The first developmental step to the generation of a functional model is to create a black box model representing the design or product s overall functionality in verb-object form. The black box is drawn as a single function block with a series of input/output flows, which are required to achieve a high-level functionality. The generation of a black box model for a Digger Dog involves determining its core functionality and then determining all input/ output flows that are required to complete the determined core functionality. Since the focus of this paper is flows, s will be the primary input/output flow focus. As previously mentioned, Digger Dog is a toy designed to simulate a dog, which makes its core functionality in verb-object form to simulate dog, shown in the black box model provided in Fig. 16. A Digger Dog has four s, on/off, sound, motion, and manual operation. The on/off control is the master control having to be set in the on position to allow simulation. Manual operation is performed by a push button that starts the simulation, while the sound/motion feature allows for a level of automation that automatically turns on the simulation. The two output s are the position of the on/off master switch and actual visible reaction from the simulation Step 2: Create Function Chains for Each. The second step to generating a subfunctional model is to generate function chains for each input flow. Each subfunction chain should consider all changes and operations that occur in each flow. Again, considering only the input flows, function chains are generated for the sound, motion, on/off, and manual operation inputs. From Rule 6 of the flow morphology, detec- Sound Fig. 17 model Motion Fig. 18 model to Function chain for the sound from a black box Electromagnetic Electromagnetic to Function chain for the motion from a black box On/Off HE to Mech. E. Mech. E. to to Reaction Fig. 19 model Function chain for the on/off from a black box Manual Operation HE to Mech. E. Mech. E. to Fig. 15 Digger Dog Fig. 20 Function chain for the manual operation from a black box model Journal of Design MAY 2008, Vol. 130 / Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

8 Manual Operation to Mech. E. Mech. E. to to Reaction Store Supply Distribute On/Off to Mech. E. Mech. E. to Motion Electromagnetic Electromagnetic to Sound User Human Guide Human Human Surface Solid Stabilize Solid Solid Visual Tail to Change Guide Distribute Leg to Change Guide Noise to Visual Auditory Fig. 21 Aggregated functional model of a Digger Dog tion of sound or motion requires the use of a sensor. Sensor functional models for detecting sound and motion are generated by applying the sensor syntax and are provided in Figs. 17 and 18, respectively. To sense sound, acoustic energy must first be imported into the system so that it can be sensed with a sense acoustic energy function block. Motion is detected by first importing electromagnetic energy into the system to be sensed with a sense electromagnetic energy function block. To turn the status s generated by the sense function blocks into control s, the processor syntax, consisting of a process status function block and a convert status to control function block, is implemented. s that can be used to activate the simulation of a Digger Dog are now generated. The on/off and manual operation inputs are switches and / Vol. 130, MAY 2008 Transactions of the AS Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

9 are modeled following the actuator syntax. The on/off switch, like the switch building block example in Fig. 10, contains the optional user status indicator via position indicator markings. The manual operation switch, however, does not have a user indicator, relying instead on the simulation to prompt the user of a proper operation. Figure 19 provides the subfunction chain for the on/off switch, and Fig. 20 provides the subfunction chain for the manual operation switch. Both subfunction chains import human energy as a means to actuate the switch. The human energy is then converted to mechanical energy, which is converted to a control. The control is carried by mechanical energy 1 to actuate the master on/off or 2 to actuate the dog simulation. The manual operation subfunction chain ends with transfer control since there is no user status indication. However, the control in the on/off subfunction chain is converted to a status that is then indicated to the user Step 3: Aggregate Function Chains Into a Functional Model. The final step is to aggregate the functional model. During this phase, subfunction chains are connected and new subfunctions may be added. The new functional model will be a comprehensive model representing the whole, unified functionality of the product. For the Digger Dog example, each of the subfunction chains have been aggregated into the energy and material subfunction chains to create the unified functional model provided in Fig. 21. The motion and sound detection have been aggregated together to use the same process status, convert status to control, and transfer control function blocks. The motion/sound control is then aggregated with the electrical energy function chain to control the flow of electrical energy via an actuate electrical energy function block in the simulation part of the functional model. The manual operation is also used to control the flow of electrical energy and is transferred to the same actuate energy function block in the simulation portion as the motion/sound detection s. The on/off control has been transferred into the master actuate electrical energy function block, and upon leaving the master actuate electrical energy function block, the control is converted to a status that is indicated to the user. The final functions to be added to the aggregated functional model are the indicate status function blocks. An indicate visual function block has been added to both of the export mechanical energy function blocks where one represents a Digger Dog s leg kicking and another represents the tail wagging. A final indicate visual function block has been added, leaving the export acoustic energy function block representing the output of the acoustic energy for a Digger Dog barking. To illustrate how each function-flow pair works in the Digger Dog system, the function-flow pairs within the aggregated functional model have been mapped to a component within the Digger Dog system. A complete component breakdown including all primary and secondary functionalities can be found on the UMR Design Repository Conclusions The grammars presented address semantic deficiencies of a model structure when generating functional models. The grammar, comprised of morphology and syntax, and the Functional Basis lexicon provide the nomenclature and structure, allowing for a more uniform functional modeling. This uniformity helps to ensure the understanding and consistent archival of design information. The addition of carrier flow information aids in the capturing and archiving of vital system information, allowing future designers to better understand the original intent and functionality of archived product information. Signal usage syntax provides templates that can be modified for design intent to create more complete and correct functional models of electromechanical products. In particular, the grammars, when combined with the previous work of Sridharan and Campbell 8, support manual creation of functional models through rote application of the rules, given a black box as a starting point. Also, as Sridharan and Campbell have previously shown, the grammars can be integrated into an automated computer application to generate functional models. Building block examples demonstrate a syntax template application with various common electromechanical components. Limitations of this work derive mainly from its inductive nature. Since all instances of functionality are not observed, there is no way to know if the grammar set is complete. However, a review of control systems literature has identified the basic control elements that must be represented in order to model electromechanical and mechatronic products. Additionally, grammars are notoriously difficult to implement. This fact can be mitigated through the use of the active center concept from the polymerization phenomenon 47,48, as utilized by Sridharan and Campbell 7,8. Future work will aim at the integration of grammar into a functional modeling CAD package so as to identify discrepancies in a functional modeling structure. The software package will provide the designer with templates based on the syntax to aid in the functional model generation. Also, to validate the uniformity of functional models when a grammar is employed, case study functional models will be generated for electromechanical products with elements of automation that rely heavily on flows for overall functionality. References 1 Stone, R., and Wood, K., 2000, Development of a Functional Basis for Design, AS J. Mech. Des., 122 4, pp Miles, L., 1961, Techniques of Value Analysis and Engineering, McGraw-Hill, New York. 3 Pahl, G., and Beitz, W., 1996, Engineering Design: A Systematic Approach, Springer, New York. 4 Hubka, V., and Ernst Eder, W., 1984, Theory of Technical Systems, Springer- Verlag, Berlin. 5 Ullman, D. G., 2002, The Design, 3rd ed., McGraw-Hill, New York. 6 Hirtz, J., Stone, R., McAdams, D., and Szykman, S. W. K., 2002, A Functional Basis for Engineering Design: Reconciling and Evolving Previous Efforts, Res. Eng. Des., 13 2, pp Sridharan, P., and Campbell, M. I., 2004, A Grammar for Functional Structures, Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Salt Lake City, UT. 8 Sridharan, P., and Campbell, M. I., 2005, A Study on the Grammatical Construction of Function Structures, Artif. Intell. Eng. Des. Anal. Manuf. 19, pp , The New Oxford American Dictionary, 2nd ed., Oxford University Press, New York. 10 Quirk, R., Greenbaum, S., Leech, G., and Svartvik, J., 1985, A Comprehensive Grammar of the English Language, Longman, London. 11 Millward, C. M., 1996, A Biography of the English Language, 2nd ed., Harcourt Brace, Fort Worth, TX. 12 Ulrich, K. T., and Eppinger, S. D., 2004, Product Design and Development, McGraw-Hill/Irwin, Boston, MA. 13 Cutherell, D., 1996, The PDMA Handbook of New Product Development, M. Rosenau, Jr., ed., Wiley, New York, Chap Fenves, S., 2001, A Core Product Model for Representing Design Information, National Institute of Standards and Technology, Gaithersburg, MD. 15 Hundal, M., 1990, A Systematic Method for Developing Function Structures, Solutions and Concept Variants, Mech. Mach. Theory, 25 3, pp Miles, L., 1972, Techniques of Value Analysis Engineering, McGraw-Hill, New York. 17 Otto, K., and Wood, K., 2001, Product Design: Techniques in Reverse Engineering, Systematic Design, and New Product Development, Prentice-Hall, New York. 18 Dieter, G., 1991, Engineering Design: A Materials and ing Approach, 2nd ed., McGraw-Hill, New York. 19 Little, A., Wood, K., and McAdams, D., 1997, Functional Analysis: A Fundamental Empirical Study for Reverse Engineering, Benchmarking and Redesign, Proceedings of the 1997 Design Engineering Technical Conferences, Sacramento, CA, Paper No. 97-DETC/DTM Uder, S. J., Stone, R. B., and Tumer, I. Y., 2004, Function Based Risk Assessment and Failure Prediction for Unmanned Space Missions, AS International Engineering Congress and Exposition, Anaheim, CA, Paper No. ICE Lough, K. G., Stone, R. B., and Tumer, I. Y., 2006, The Risk in Early Design RED Method: Likelihood and Consequence Formulations, AS Interna- Journal of Design MAY 2008, Vol. 130 / Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see

10 tional Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 22 Moon, S. K., Kumara, S. R. T., and Simpson, T. W., 2006, Data Mining and Fuzzy Clustering to Support Product Family Design, AS International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 23 Steva, E. D., Rice, E. N., Marion, T. J., Simpson, T. W., and Stone, R. B., 2006, Two Methodologies for Identifying Product Platform Elements Within an Existing Set of Products, AS International Design Engineering Technical Conferences, Philadelphia, PA. 24 Jordan, R. L., Wie, M. V., Stone, R. B., Wang, J., and Terpenny, J., 2005, A Group Technology Based Representation for Product Portfolios, AS International Design Engineering Technical Conferences, Long Beach, CA. 25 Bohm, M., and Stone, R., 2004, Representing Product Functionality to Support Reuse: Conceptual and Supporting Functions, Proceedings of DETC2004, Salt Lake City, UT, Paper No. DETC Bohm, M., Stone, R., and Szykman, S., 2005, Enhancing Virtual Product Representations for Advanced Design Repository Systems, AS J. Comput. Inf. Sci. Eng., 5 4, pp Bohm, M. R., Stone, R. B., Simpson, T. W., and Steva, E. D., 2006, Introduction of a Data Schema: The Inner Workings of a Design Repository, AS International Design Engineering Technical Conferences, Philadelphia, PA. 28 Van Wie, M., Bryant, C., Bohm, M., McAdams, D., and Stone, R., 2005, A General Model of Function-Based Representations, Artif. Intell. Eng. Des. Anal. Manuf., 19 2, pp Bryant, C., Stone, R., McAdams, D., Kurtoglu, T., and Campbell, M., 2005, Concept Generation From the Functional Basis of Design, International Conference on Engineering Design, ICED, 05, Melbourne, Australia. 30 Vucovich, J., Bhardwaj, N., Ho, H.-H., Ramakrishna, M., and Thakur, M., 2006, Concept Generation Algorithms for Repository-Based Early Design, AS International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 31 Bryant, C. R., McAdams, D. A., Stone, R. B., Kurtoglu, T., and Campbell, M. I., 2006, A Validation Study of an Automated Concept Generator Design Tool, AS International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 32 Hutcheson, R. S., Jordan, R. L., Stone, R. B., Terpenny, J. P., and Chang, X., 2006, Application of a Genetic Algorithm to Concept Variant Selection, AS International Design Engineering Technical Conferences, Philadelphia, PA. 33 Attaluri, V., McAdams, D. A., Stone, R. B., and Crescenzo, A. D., 2006, Visual Representations as an Aid to Concept Generation, AS International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 34 Galvao, A. B., and Sato, K., 2006, Incorporating Affordances into Product Architecture: Methodology and Case Study, AS International Design Engineering Technical Conferences, Philadelphia, PA. 35 Park, J., and Simpson, T. W., 2005, An Activity-Based Costing Method for Product Family Design in the Early Stages of Development, AS International Design Engineering Technical Conferences, Long Beach, CA. 36 Stone, R. B., Tumer, I. Y., and Wie, M. V., 2005, The Function-Failure Design Method, AS J. Mech. Des., 127 3, pp Bohm, M., Stone, R. B., and Szykman, S., 2002, Decomposition-Based Failure Mode Identification Method for Risk-Free Diagram in Large Systems, AS J. Mech. Des., submitted. 38 Hutcheson, R. S., McAdams, D. A., Stone, R. B., and Tumer, I. Y., 2006, A Function-Based Methodology for Analyzing Critical Events, AS International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 39 Nagel, R. L., Stone, R. B., and McAdams, D. A., 2006, A Modeling Methodology for Automation of Manual and Time Dependent es, AS International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Philadelphia, PA. 40 Nise, N. S., 2004, Systems Engineering, Wiley, New York. 41 Chen, D., and Törngren, M., 2004, A Systematic Approach for Identifying Operational Relationships in Embedded Computer Systems, EURO- MICRO Conference, Rennes, France. 42 Chen, L., Jayaram, M., and Xi, J. F., 2002, A New Functional Representation Scheme for Conceptual Modeling of Mechatronic Systems, Design Engineering Technical Conferences and Computer and Information in Engineering Conference, Montreal, Canada. 43 Jayaram, M., Chen, L., and Xi, J. F., 2003, Functional Modeling of Complex Mechatronic Systems, Design Engineering Technical Conferences and Computer and Information in Engineering Conference, Chicago, IL. 44 Rajan, J. R., 2002, A Robust Functional Modeling Method in Product Design, M.S. thesis, The University of Texas at Austin, Austin, pp Rajan, J. R., Stone, R. B., and Wood, K. L., 2003, Functional Modeling of Systems, International Conference on Engineering Design, Stockholm. 46 Gemmy Industries Corporation, Digger Dog 47 Progelhof, R. C., 1993, Polymer Engineering Principles: Properties and Tests for Design, Hanser, Munich. 48 Gowariker, V. R., Viswanathan, N. V., and Sreedhar, J., 1986, Polymer Science, Wiley, New York / Vol. 130, MAY 2008 Transactions of the AS Downloaded 22 Sep 2011 to Redistribution subject to AS license or copyright; see