A Signal Grammar to Guide Functional Modeling of ......• Grammar: the whole system and structure...

1

etmtipemtac

deiiadalfns

p1R

J

Downlo

Robert L. Nagele-mail: [email protected]

Jayson P. Vucoviche-mail: [email protected]

Robert B. Stonee-mail: [email protected]

Daniel A. McAdamse-mail: [email protected]

Design Engineering Laboratory,University of Missouri–Rolla,

Rolla, MO 65409-0210

A Signal Grammar to GuideFunctional Modeling ofElectromechanical ProductsIn modern product design methodologies, designers are increasingly required to combineelements spanning multiple engineering domains, thus blurring the boundaries betweenengineering disciplines. Functional modeling with the Functional Basis provides thebasic tools required to integrate system models at the conceptual level; however, there isa lack of unified rules to address the structure of functional models. This article coversthe development of a signal grammar for functional modeling with a Functional Basis. Atthe conceptual level, signal flows represent the information vital to a proper systemoperation. Signal flows are explored through their Functional Basis lexicon and primary/carrier flow relationships. A grammar, consisting of morphology and syntax, is presentedand applied to a set of electromechanical, component-based building block examples. Tofurther demonstrate the application of signals in functional modeling, an electromechani-cal product is explored functionally with the application of the signal grammar.�DOI: 10.1115/1.2885185�

IntroductionElectromechanical design often requires designers to create an

ngineering solution that spans multiple engineering domains. Of-en, this forces engineers to synergistically consider design ele-

ents from numerous engineering fields such as mechanical, elec-rical, and computer. For successful designs to emerge, thentegration of engineering domains must be considered through allhases of product design, both conceptual and physical. Designlements must work together flawlessly, requiring adequate com-unication, monitoring, processing, and decision-making abili-

ies. The modeling of information, i.e., signal flow, is vital forccurate and complete design models that support the design pro-ess.

One approach to developing system models to support multi-isciplinary engineering projects and products is functional mod-ling. A functional model is a description of a product or processn terms of the elementary functions that are required to achievets overall purpose �1�. A function is an operation by a device orrtifact on a flow of material, energy, or signal passing through theevice or artifact. While the concept of defining product functions a step in the early phases of product design has existed in theiterature since at least the mid-19th century �2–4�, it still lacks theormalization of other accepted engineering design analysis tech-iques. At the same time, however, functional modeling offersignificant capabilities for product design in several areas �1�.

• Systematic methods to model product functionality. Func-tionality is arguably one of the fundamental constructs ofproduct design. The ability to model a product’s functional-ity independent of and prior to form is critical for productsthat meet customer demands.

• Creativity in concept generation. The ability to decompose acomplicated task into simpler pieces is a critical step in thesynthesis process �5�. Identifying the key functionality of aproduct to be designed significantly increases the ability ofdesigners to break problems down and find innovative solu-tions.

• Archival and reuse of design knowledge. Products are tran-

Contributed by the Design Theory and Methodology Committee of ASME forublication in the JOURNAL OF MECHANICAL DESIGN. Manuscript received December4, 2006; final manuscript received May 14, 2007; published online March 25, 2008.
eview conducted by Yan Jin.
ournal of Mechanical Design Copyright © 20

aded 22 Sep 2011 to 165.91.89.105. Redistribution subject to ASME

sient, and the design process and decisions that led to theproduct are even more fleeting. A functional model providesa record of the abstract requirements of the embodied prod-uct. Recording the relationship between function and prod-uct components allows future designs to leverage the pastknowledge of previous designs and designers.

• Product architecture definition. The functionality of a prod-uct, arranged graphically as a functional model, can guidethe architecture of a product. Groups of functions operatingon common flows �the connections between the functions�lead to modules or platforms on which a family of productsmay be designed.

Accepting the premise that functional modeling is an importantstep in a product design process, the general approach to func-tional modeling provides the graphical tools required to develop acomplete model of a product during conceptual design. When theFunctional Basis is used for terminology, there is consistency ofnomenclature that allows for a universal understanding of functionand flow �6�. The Functional Basis, however, does not explicitlyaddress consistency of model structure. Structure must be pro-vided through a well-defined grammar consisting of morphologyand syntax. Without a properly defined grammar, difficulty arisesin the development of uniform and synergistic models that com-pletely and accurately represent all engineering domains. Materialand energy flows have an established grammar built from trial anderror conventions �7,8�. Signal flows, however, tend to be muchmore ambiguous. An anecdotal study by the authors of 20 elec-tromechanical products that were dissected and modeled function-ally with the Functional Basis revealed vastly different techniqueson how signal flows were modeled. Thus, there still exists thepossibility for flows and functions to be incorrectly used, leadingto modeling errors.

To overcome this deficiency, a grammar consisting of morphol-ogy and syntax is needed to provide structure to functional mod-eling with the Functional Basis. In its current form, the FunctionalBasis is best thought of as a lexicon, requiring the structure ofgrammar for consistent usage. From linguistics, we can find thefollowing definitions for lexicon, morphology, syntax, and gram-mar �9–11�.

• Lexicon: the vocabulary of a language; the complete set of
meaningful units in a language.
MAY 2008, Vol. 130 / 051101-108 by ASME

license or copyright; see http://www.asme.org/terms/Terms_Use.cfm

mg

mtdTmatto

2

tagFnopf

iPdpha�dtfBamaaawctmd

0

Downlo

• Morphology: the sum of the relationships defining the com-binations of the smallest meaningful units of a language.The smallest meaningful units of a language are called mor-phemes.

• Syntax: the arrangement of words and phrases to createwell-formed sentences in a language.

• Grammar: the whole system and structure of a language orof languages, in general, usually taken as consisting of syn-tax and morphology and sometimes also phonology andsemantics.

Modifying the above definitions to the domain of functionalodeling, we define functional lexicon, morphology, syntax, and

rammar as follows.

• Functional lexicon: the entire set of function and flow ter-minology that makes up the Functional Basis.

• Functional morphology: the arrangement of function andflow terms into function-flow pairs.

• Functional syntax: the overall arrangement of function andflow pairs into well-formed function chains and aggregatedfunctional models describing a product, system, or artifact.

• Functional grammar: the whole system and structure of theFunctional Basis consisting of functional morphology andfunctional syntax in the form of modeling templates.

This paper develops a signal grammar consisting of a set oforphology rules and a set of syntax rules to increase the consis-

ency of signal flow usage in functional modeling. Signals areefined in Sec. 3, and their Functional Basis lexicon is presented.he signal grammar consisting of morphology and syntax is for-ulated in Sec. 4. In Sec. 5, the signal grammar is then applied toseries of building block examples to show how they might be

ransformed and applied as functional modeling templates, andhrough an example of electromechanical product, the integrationf signal flows into an overall functional model is presented.

Prior WorkThe technique of functional modeling allows a product designer

o graphically represent both function and flow in an early designnd can be found in many texts on engineering design methodolo-ies �3,5,12–18�. When functional modeling is performed with theunctional Basis, product designers have at their disposal termi-ology for function and flow terms where functions take the formf action verbs and flows take the form of nouns �1,6�. The com-lete taxonomy of terms provided by the Functional Basis can beound in Ref. �6�.

The Functional Basis in its current form is a refinement of pastdeas and works to develop a language of functional modeling.ahl and Beitz presented the idea of a functional basis for productecomposition with material, energy, and signal flows �3�. Hundalresented a further refined set of function and flow classes �15�;owever, this work lacks a separate function category for signalsnd is further refined by Little et al. with the Functional Basis Set19�. Stone and Wood then presented the Functional Basis as aesign language of function and flow terms with precise defini-ions �1�. The Functional Basis is then reconciled into its currentorm by Hirtz et al. �6�. Functional modeling with a Functionalasis has spawned research into a wide array of product designpplications that would benefit from functional syntax and gram-ar. Functional modeling techniques using the Functional Basis

re being applied to concept generation, design knowledge storagend reuse, early risk analysis, cost optimization, component reuse,nd conceptual design visualization �20–37�. Functional modelingith a functional basis is also being applied to modeling pro-

esses, events, and human-product interactions �38,39�. A func-ional syntax and a set of functional grammars will promote a

ore consistent design synergy between each of these areas of
esign research.
51101-2 / Vol. 130, MAY 2008


In an effort to standardize the assembly of functional modelsand to shorten the learning curve, Sridharan and Campbell putforth grammar rules in the form of function structures �7,8�. Thegrammar rules are based on products dissected and modeled withthe reconciled Functional Basis and are archived in the Universityof Missouri-Rolla �UMR� Product Design Repository. The gram-mar rules are meant to capture all possible flows between functionstructures. Some problems with their grammar rules are that theirrules were only established for energy and material flows due toan inherent ambiguity of signal flows that Sridharan and Campbellattributed to environmental unknowns. Because signal flows wereomitted from their grammar, it becomes difficult to fully utilizethe function grammar set to generate an accurate functional modelintegrating multiple engineering domains.

In an electromechanical design, signals are vital to establish thesynergy among engineering domains. Increased recognition of theneed for an integrated design among engineering disciplinesthrough the acceptance of fields such as mechatronics has in-creased the need for a clarified methodology to systematicallyrepresent system level signal flows in functional models.

At the heart of many mechatronic systems lies a control schemebased on system sensory data, requiring comprehensive integra-tion of sensors and actuators. Traditionally, control systems aremodeled via a block diagram, where individual blocks representan element of either the controller or the system and are connectedwith lines representing the flow of information �40�. Blocks aretypically labeled to denote what dynamics they represent and con-tain a transfer function modeling the dynamic response of thesystem element. Block diagrams fall short in aiding the overallsystem design due to a failure to functionally represent all com-ponent interactions, whether through signal, energy, or materialflows.

In an effort to model control systems at a design level, Chenand Törngren researched the functional requirements of controlsystems, giving primary focus to informational flow �either data,control, or mixed� and its characteristics as applicable in a controlsystem �41�. The research of Chen and co-workers established afunctional modeling methodology for mechatronic systems thattries to fill the void in typical control system modeling techniquesand to bridge the gap between functional modeling of controlsystems and all other noncontrol based product interactions�42,43�. These methods, however, do not present a methodologyto integrate system interactions not requiring direct control intotheir model.

Rajan �44� and Rajan �45� applied functional modeling to con-trol systems by developing a four-step methodology for modelingcontrol systems based on the reconciled Functional Basis. Theirwork looks at the development of the model for the controller andits associated input transducers. Through modeling a wide array ofinput transducers, Rajan et al. established a signal modeling meth-odology to model the transmitted signal and energy flows withineach transducer. Their research, however, considers the signal andenergy flows separately, not making the connection that energy isthe carrier of the signal flow. The models contain knowledge thatis useful for product dissection and failure analysis but are farmore detailed than can be achieved during the functional stages ofconceptual design.

3 Signal LexiconThe reconciled Functional Basis by Hirtz et al. �6� establishes a

set of definitions, which hold in them the guidelines governinghow functions and flows should interact. This function and flowterminology for signals constitutes a lexicon for signal represen-tation. In the following subsections, the signal as a functionalmodeling flow is defined, and a signal lexicon, as defined by theFunctional Basis, is provided.

3.1 Signal Defined. What is a signal flow? A signal is typi-
cally defined as information about a system or its surroundings. In
Transactions of the ASME


Rdosfl

ertwccm

suflpbmpsccrrflpima

tdosctvfl

S

J

Downlo

ef. �17�, signal flows are defined as information for the “internalecision-making capability of a device or sensory data provided tor by a device or process.” Stone and Wood further defined aignal by clarifying that a signal is either a material or an energyow with the specialized purpose of carrying information �1�.A signal, while being its own class, is actually a subset of either

nergy or material. All signals are some form of energy or mate-ial, but not all energies and materials are signals. This is due tohe very nature of a signal. Since signal flows are information thatill enter into, out of, or travel through a system, they require a

arrier of sorts. A mailbox flag is an example of a material energyarrier where the flag carries the discrete control signal to pick upail.Often, it is important during the design phase to represent the

ignal flow carrier relationship. This relationship is representedsing primary/carrier signal flow properties. Primary/carrier signalow properties, shown in Fig. 1, allow the designer to represent arimary flow required to meet the input/output requirements of thelack box model and its supporting carrier flow that aids the pri-ary flow in the completion of its black box requirements. A

rimary flow, being of principle influence to the system, is de-cribed by each function block that it passes through. Primary/arrier flow properties are typically consistent across functionhains; however, there are times when it may be necessary toepresent changed functionality of a flow that in a prior block wasepresented by a carrier. Typically, this occurs when the carrierow changes its form. Due to this ability for a primary/carrierroperty to change, it can be said that primary flow properties arendependent of the function chain. From the mailbox example, the

aterial flow �mailbox flag� is the carrier flow and the signal isgain the primary flow.

3.2 Flow Lexicon. A signal, at the primary level of the Func-ional Basis, is a flow with the purpose of providing vital systemata. The Functional Basis clearly defines signal flows at the sec-ndary and tertiary levels �6�. Signal flows are defined at theecondary level as being one of two separate flow types, status orontrol, which are then further defined at the tertiary level. At thisertiary level, status can be auditory, olfactory, tactile, taste, orisual, while a control can either be analog or discrete. Theseows are defined below �6�.

ignal

• Status: a condition of some system, as in information aboutthe state of the system

� Auditory: a condition of some system as displayed by asound� Olfactory: a condition of some system as related by thesense of smell or particulate count� Tactile: a condition of some system as perceived bytouch or direct contact� Taste: a condition of some dissolved substance as per-ceived by the sense of taste� Visual: a condition of some system as displayed bysome image

• Control: a command sent to an instrument or apparatus to

primaryFunction

Primary FlowFunction

Primary Flowcarrier

FunctionPrimary Flow

carrier carrier

carrier

primary primary

primary

Fig. 1 Function blocks illustrating primary and carrier flows

regulate a mechanism

ournal of Mechanical Design


� Analog: a control signal sent by direct, continuous,measurable, variable physical quantities� Discrete: a control signal sent by separate, distinct,unrelated, or discontinuous quantities

3.3 Function Lexicon. The reconciled Functional Basis pro-vides a set of functions that act on, with, or in response to signalflows. From the Functional Basis, there are two functions, actuateand regulate, defined below, requiring the input of a signal tocontrol the magnitude of another flow in a separate flow chain �6�.

• Actuate: to commence the flow of energy, signal, or materialin response to an imported control signal

• Regulate: to adjust the flow of energy, signal, or material inresponse to a control signal such as a characteristic of flow

The Functional Basis also provides a set of functions defined tooutput signal flows representing system information in response toanother flow. These flows, under the primary function class ofsignal, are defined to ascertain and provide vital system informa-tion back into the system or to the user. System information isprovided in the form of a signal flow. The functions and theirdefinitions are provided below �6�.

Signal: to provide information on a material, energy, or signalflow as an output signal flow

• Sense: to perceive or become aware of a flow

� Detect: to discover information about a flow� Measure: to determine the magnitude of a flow

• Indicate: 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 mindor eye

• Process: to submit information to a particular treatment ormethod having a set number of operations or steps.

There is also a set of function terms in the Functional Basis thatare defined to take in or put out control signals �as well as otherflows� from a system. These terms, under the primary functionclass channel, are import and export and are commonly usedwhen the system emits a control signal outside of its boundary tobe received either by another system or by itself. The import andexport function terms are defined below �6�.

• Import: to bring in a flow �material, energy, signal� fromoutside the system boundary

• Export: to send a flow �material, energy, signal� outside thesystem boundary

Finally, the function convert also operates on control signalsand can transform their state. The control function term is definedbelow �6�,

• Convert: to change from one form of a flow �material, en-ergy, signal� to another. For completeness, any type of flowconversion is valid.

4 Signal GrammarA grammar has been enumerated from functional models mod-

eled with the Functional Basis for both energy and material flows�7,8�; however, signals, while also having inherent Functional Ba-sis guidelines, have no previously established usage grammar. Inthe following subsections, a signal grammar based on the Func-tional Basis for function and flow terminology is presented. Thesignal grammar consists of morphology guiding the interconnec-tivity of function and flow terms and syntax providing functional
modeling templates. The developed grammar provides a structure
MAY 2008, Vol. 130 / 051101-3


afla

dcgtsat

0

Downlo

nd templates to aid in the manual and automatic assembly ofunctional models and guides the assembly of subfunctions, uti-izing nodes to clearly establish the location of system boundariesnd the required input and output flows.

4.1 Signal Morphology. The following 11 rules have beenerived from the definitions provided by the Functional Basis andonstitute the morphology for signal flows. Signal morphologyuides the arrangement of signal related function and flow termshrough a functional model and is meant to clarify how and whenignal flows are to be applied in electromechanical products. Toid in the visualization of the morphology, Rules 3–12 are illus-rated in Fig. 2.

• Rule 1: Use status signals to provide information on audi-tory, olfactory, tactile, taste, or visual states of the system.

• Rule 2: Use control signals to send an analog or discreteoperational command to an instrument or apparatus.

• Rule 3: Use a primary flow to denote a signal and a carrierflow to denote its energy or material carrier.

• Rule 4: Use the actuate function to discretely toggle a flow�material, signal, energy�.

• Actuate functions require a discrete control signal totoggle state.

• Rule 5: Use the regulate function to adjust a flow quantity�material, signal, energy� in an analog manner.

• Regulate functions require an analog control signal toadjust flow quantity.

• Rule 6: Use the sense function to detect or measure a flow�material, signal, energy�.

• Sense functions require an input of the flow of interest tooutput a status signal representing data collected.

• Rule 7: Use the indicate function to provide system status tothe user.

• Indicate functions end flow paths; thus, status flows ex-iting an indicate function block leave the system and donot connect to other function blocks.

• Indicate functions do not receive a carrier flow.

• Rule 8: Use the process function to execute a series of op-erations to extract conditional information on a signal flow.

flow of interest(energy,material

or signal)

RegulateFlow

analog controlsignal

SenseFlow

statussignal

flow of interest

TransferSignalcarrier flow

(material orenergy)

primary flow(signal)

IndicateStatusstatus

signal

ProcessStatus

statussignal

ConvertSignal

signal signal

ImportControl

controlsignal

ExportControl

controlsignal

TransferSignal

signal

ActuateFlow

discrete controlsignal

Rule 4Rule 3

Rule 5 Rule 6

Rule 7 Rule 8 Rule 9

Rule 10 Rule 11 Rule 12

Fig. 2 Signal flow morphology rules

• Either control or status flows can enter process functions;

51101-4 / Vol. 130, MAY 2008


however, respective entering flows must also exit.

• Rule 9: Use the convert function to perform the conscienceact of changing a signal flow’s type.

• A status flow input to the convert function should outputas a system-usable control signal.

• A control flow input to the convert function should out-put as a status flow.

• Rule 10: Use the import function to bring a control signalflow from the outside of the system boundary to the insideof the system boundary.

• Flow arrows should be drawn into an input functionblock to represent flow into the system.

• Rule 11: Use the export function to send a signal flow out-side of the system boundary.

• Flow arrows should be drawn leaving the export functionto represent control flowing from the system.

• Rule 12: Use the transfer function to move a signal flowthrough 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 signal morphol-ogy rules are used to build syntax for signals. The syntax mani-fests itself as functional modeling templates that can be modifiedand inserted into a functional model, aiding in the manual orautomatic assembly of functional models, thus increasing the ac-curacy of product and design representation. Each syntax rule isexplained and visually represented in the following subsections.

4.2.1 Actuator. An actuator, shown in Fig. 3, is a discretecontrol device used to turn another flow on or off. In a conceptualdesign, if it is known that a flow will be toggled, an actuatorshould be implemented. To functionally build an actuator, the ac-tuate function must be used in conjunction with Rules 3 and 4. Acontrol signal, its carrier, and the flow to be toggled should beimported with import function-flow blocks, as shown to the left ofthe functional requirement arrow in Fig. 3. Then, following Rule12, a transfer control function-flow block represents the routing ofthe control signal to an actuate flow function-flow block. Option-ally, the actuator can indicate its status. To indicate the status,Rule 9 is followed to convert the control signal to a status signaland Rule 7 is followed to indicate the status through an indicatestatus function-flow block.

4.2.2 Regulator. A regulator, shown in Fig. 4, is an analogcontrol device to adjust a flow in a variable manner. When it isknown in a conceptual design that a flow is to be adjusted in avariable manner, a regulator should be implemented. To function-ally build a regulator, the regulate term must be used in conjunc-tion with Rules 3 and 5. To implement a regulator, a control sig-nal, its carrier, and the flow to be adjusted should be importedwith import function-flow blocks, as shown to the left of the func-

ImportFlow

ImportControl

ImportFlow

ActuateFlow

TransferFlow

ExportFlow

ImportControl

TransferControl

ConvertControl to

StatusIndicateStatus

ReactionOptional User

Status Indicator(Rules 7 & 9)

Fig. 3 Actuator syntax rule

tional requirement arrow in Fig. 4. The control signal and its



ctrcfl

dcdttiabwbc

btFbt

wditusfpe

J

Downlo

arrier are routed to the regulate flow function-flow block via aransfer control function-flow block following Rule 12. If theegulator indicates its status, Rule 9 is followed to convert theontrol signal to a status with a convert control to status function-ow block, and Rule 7 is followed to indicate status.

4.2.3 Sensor. A sensor, shown in Fig. 5, is a device used toetect or measure a flow and then output a signal representingollected information. Sensors would be used during conceptualesign if a designer realizes that a design must ascertain informa-ion about itself or its surroundings. To functionally build a sensor,he sense term must be used in conjunction with Rules 3 and 6. Tomplement a sensor, transfer a flow �material, energy, or signal� to

sense flow function-flow block. The sense flow function-flowlock outputs primary status flow and its respective carrier flow,hich can then be transferred with a transfer status function-flowlock by Rule 12. The final destination of the status flow andarrier can be the system, the user, or both.

The sense function can be further detailed at the tertiary levely the reconciled Functional Basis with its tertiary functions de-ect and measure. The general sensor functional model, shown inig. 5, can modified to reflect the increased detail of tertiary termsy using one of the two tertiary terms in place of the sense func-ion.

4.2.4 Indicator. An indicator, shown in Fig. 6, is any deviceith the goal of providing vital system information to the user. Aesigner might use an indicator during a conceptual design whent is known that some form of feedback is required from the sys-em. To functionally build an indicator, the indicate term must besed in conjunction with Rule 7. To implement an indicator, run atatus flow from the function-flow block from which system in-ormation should be obtained. An indicator is the exception to therimary/carrier rule �Rule 3� since it can be as simple as the op-ration of the system or as complex as a series of components

ImportFlow

ImportControl

ImportFlow

RegulateFlow

TransferFlow

ExportFlow

ImportControl

TransferControl

ConvertControl to

StatusIndicateStatus

ReactionOptional User

Status Indicator(Rules 7 & 9)

Fig. 4 Regulator syntax rule

ImportFlow

TransferFlow

SenseFlow

SenseFlow

TransferStatus

Material, Energy,or Signal Flow

Fig. 5 Sensor syntax rule

FunctionFlow

IndicateStatus

IndicateStatus

Status

Fig. 6 Indicator syntax rule



providing full diagnostics on system behaviors; in either case,however, an indicator is not required to send the signal outside ofthe system boundary. An indicate status function-flow block endsa flow path �Rule 7�, thus the status flow that exits an indicatestatus should not enter another function block.

As with the sense function, the indicate function can be furtherdetailed at the tertiary level by the reconciled Functional Basiswith its tertiary functions track and display. The general indicatorfunctional model, shown in Fig. 6, can be modified to reflect theincreased detail of tertiary terms by using one of the two tertiaryterms in place of the indicate function.

4.2.5 Processor. A processor, shown in Fig. 7, is any devicethat analyzes a status signal obtained from a sensor that has as-certained information, either internal or external to the system.Following signal analysis, the processor sends control informationto system elements. A processor might be used during a concep-tual design if a designer knows that the product will need to ana-lyze the state on a series of conditions and make decisions basedon the analysis. To functionally build a processor, the process termmust be used in conjunction with Rules 3 and 8. To use a proces-sor, run a primary status flow and a carrier flow into a processstatus function-flow block. Following Rule 9, to get a system us-able control signal, connect the process status function-flow blockto a convert status to control function-flow block with anotherprimary status flow and carrier flow pair. Then connect the convertstatus to control to a transfer control function-flow block with aprimary control signal and carrier flow. By the application of Rule12, the control and its carrier flow is routed via a transfer controlfunction-flow block to the controlled system elements.

4.2.6 Receiver. A receiver, shown in Fig. 8, is used to bring acontrol signal into the system. To functionally build a receiver, theimport term must be used in conjunction with Rules 3, 10, and 12.To implement a receiver, a new control signal flow and its respec-tive carrier must be imported into the system and thus cross thesystem boundary, as shown to the left of the functional require-ment arrow in Fig. 8. The primary and carrier flows are thenrouted into the overall system by tying the import controlfunction-flow block to a transfer control block.

4.2.7 Emitter. An emitter, shown in Fig. 9, is used to send acontrol signal from the system. To functionally build an emitter,the export term must be used in conjunction with Rules 3, 11, and12. To implement an emitter, run a control signal flow and itscarrier flow through a transfer control function-flow block. Then,tie the control signal and its carrier to an export control function-

ProcessStatus

ProcessStatus

ConvertStatus toControl

TransferControl

Fig. 7 Processor syntax rule

ImportControl

ImportControl

TransferControl

Fig. 8 Receiver syntax rule

MAY 2008, Vol. 130 / 051101-5


flet

5

fcc

etTt

absrBrRtfltttif

lPooflcFccap

ta

0

Downlo

ow block. From the export control function-flow block, draw anxiting control signal flow and its carrier to represent them leavinghe system boundary.

ApplicationAs an application of the signal usage grammar, consider the

ollowing building block examples representing five basic types ofontrol systems. Following that, a complete example of a moreomplicated electromechanical product is presented.

5.1 Building Block Examples. The following building blockxamples investigate the aforementioned signal flow syntax: ac-uator, regulator, sensor, indicator, processor, receiver, and emitter.he syntax is matched to individual components to show how

hey might be applied to represent an actual engineered system.

5.1.1 Switch. A switch is a mechanical device based on thectuator syntax. It is designed to either initiate or terminate a flowased on one of its two discrete states. Provided in Fig. 10 is aample functional model of a switch. The operation of the switchequires imported mechanical energy to change the switch state.y Rule 3 for primary and carrier flows, mechanical energy is

epresented as the carrier flow used to set the switch state. Byule 4 for actuate functions, a discrete control signal, carried by

he mechanical energy, is used to actuate the electrical energyow. It is important to note that the mechanical energy used to set

he switch state is separate from the electrical energy that will passhrough the switch. For user feedback, Rule 9 for convert func-ions is applied to convert the control signal to a status, and thendicator syntax is applied via morphology Rule 7 for indicateunctions.

5.1.2 Valve. A valve is a mechanical device based on the regu-ator syntax. It is designed to adjust a flow in a variable manner.rovided in Fig. 11 is a sample functional model of a valve. Theperation of the valve requires mechanical energy to be impartedn the valve to regulate flow. By Rule 3 for primary and carrierows, mechanical energy is functionally represented as the signalarrier used to perform the work required to regulate the flow.ollowing Rule 5 for regulate functions, a control signal flow,arried by the mechanical energy, is used to set the flow rate. Theontrol signal is converted to a status signal following Rule 9, andn indicator syntax is applied via Rule 7 for indicate functions torovide user feedback.

5.1.3 Transistor. A transistor is an electrical device based onhe regulator syntax and Rule 5. It is used in electronic devices todjust the flow of electrical energy. Provided in Fig. 12 is a

ExportControl

TransferControl

ExportControl

Fig. 9 Emitter syntax rule

Switch

ImportEE

ActuateEE

TransferEE

ExportEE

ImportControl

TransferControl

ConvertControl

to Status IndicateStatus

ElectricalEnergy

CS (ME)

ME ME

ME

ME

ME (reaction force)

Fig. 10 Switch schematic and functional model

51101-6 / Vol. 130, MAY 2008


sample functional model of a transistor. Transistors do not inher-ently provide user feedback; thus, the sample functional model inFig. 12 does not include the optional indicator syntax. The opera-tion of a transistor is controlled though an applied voltage signal�electrical energy� to the transistor’s base, which allows a current�electrical energy� to pass. The voltage signal is a signal/energyexecutor whose applied value changes the current flow by alteringthe transistor’s configuration. The relationship between the signalflow and the electrical energy carrier is represented functionallyby following Rule 3 for primary and carrier flows. In a perfecttransistor, there would be no interaction between the signal/energyexecutor �voltage signal� and the electrical energy �current� whoseflow is being controlled.

5.1.4 Thermostat/Processor. A thermostat is based on the sen-sor syntax and follows Rule 6. It is designed to detect or measurethermal energy and provide a primary status signal carried by anelectrical energy flow. Provided in Fig. 13 is a sample functionalmodel of a thermostat transferring system information into a func-tional model of a signal processor. The signal processor is basedon the processor syntax following Rule 8. The signal processoranalyzes the status signal obtained from the thermostat, convertsthe status to a control signal, and transfers the control signal to thesystem. The control signal transferred into the regulator system�the four functions operating on the flow of electrical energy� iscarried by an electrical energy flow that is used to regulate theflow of electrical energy in the example. The regulator system is

ImportLiquid

RegulateLiquid

TransferLiquid

ExportLiquid

ImportControl

TransferControl

ConvertControl

to Status IndicateStatus

ValveCS (ME)

Liquid

ME ME

ME

ME

ME (reaction force)

Fig. 11 Valve schematic and functional model

Transistor

ImportEE

RegulateEE

TransferEE

ExportEE

ImportControl

TransferControl

ElectricalEnergy

CS (EE)EE EE

EE

Fig. 12 Transistor schematic and functional model

o tElectrical Energy

CS (TE)Thermostat

ImportThermal E

SenseThermal E

TransferStatus

ProcessStatusEE EE


TransferControlEE EE

TE TE

ImportEE

RegulateEE

TransferEE

ExportEE

EE

Fig. 13 Thermostat/processor schematic and functional
model


bt

tiflstntecteeecrt

eamsodiADsmns

J

Downlo

uilt following the regulator syntax and Rule 5 for regulate func-ions.

5.1.5 IR Emitter/Detector. An IR emitter is based on the emit-er syntax which follows Rule 11 for export functions. Its purposes to export a control signal carried by an electromagnetic energyow outside of the system. An IR detector is based on the receiveryntax, which follows Rule 10 for import functions. An IR detec-or’s purpose is to import a control signal carried by electromag-etic energy into the system. Provided in Fig. 14 are sample func-ional models of both an IR emitter and an IR detector. The IRmitter sends an electromagnetic energy signal, which, by Rule 3,arries a discrete control signal. The control signal is detected byhe IR detector, which acts as a switch where the signal/energyxecutor is an electromagnetic control signal mix that actuates anlectrical energy flow. The electromagnetic energy is converted tolectrical energy and applied to the transistor, thus activating theurrent flow through the transistor. In the example, the emitter andeceiver syntaxes are used in conjunction with an actuator syntaxo actuate an electrical energy flow in a system.

5.2 Electromechanical Product Example: Digger Dog. Thelectromechanical dog simulator, Digger Dog, has been dissectednd modeled functionally following the three-step functionalodeling procedure outlined by Stone and Wood �1�. Digger Dog,

hown in Fig. 15, uses one of three input options to start a seriesf events �kicking, barking, and tail wagging� to simulate a dogigging a hole in the yard �46�. As such, the Digger Dog products a signal-rich environment in which to test the signal grammars.udio and motion sensors allow for a level of automation where aigger Dog senses ambient sounds and motion to automatically

tart its simulation events. A third input option is a manual “try-e” button that, when pressed, starts the simulation events. When

ot in operation, a Digger Dog sits idle waiting for a controlignal.

ImportControl

ConvertControl

ExportControl

ImportControl

ConvertControl

TransferControl

ImportEE

ActuateEE

TransferEE

ExportEE

IR Emitter

IR Detector

IR Emitter/Detector CS (EM)

ElectricalEnergy

CS (EE)

EE EE EM EM

EM EM EE

EE

Fig. 14 IR emitter/detector schematic and functional model

Fig. 15 Digger Dog



5.2.1 Step 1: Generate Black Box Model. The first develop-mental step to the generation of a functional model is to create ablack box model representing the design or product’s overall func-tionality in verb-object form. The black box is drawn as a singlefunction block with a series of input/output flows, which are re-quired to achieve a high-level functionality.

The generation of a black box model for a Digger Dog involvesdetermining its core functionality and then determining all input/output flows that are required to complete the determined corefunctionality. Since the focus of this paper is signal flows, signalswill be the primary input/output flow focus.

As previously mentioned, Digger Dog is a toy designed tosimulate a dog, which makes its core functionality in verb-objectform to simulate dog, shown in the black box model provided inFig. 16. A Digger Dog has four signals, on/off, sound, motion, andmanual operation. The on/off control signal is the master controlhaving to be set in the “on” position to allow simulation. Manualoperation is performed by a push button that starts the simulation,while the sound/motion feature allows for a level of automationthat automatically turns on the simulation. The two output signalsare the position of the on/off master switch and actual visiblereaction from the simulation.

5.2.2 Step 2: Create Function Chains for Each Flow. The sec-ond step to generating a subfunctional model is to generate func-tion chains for each input flow. Each subfunction chain shouldconsider all changes and operations that occur in each flow.

Again, considering only the signal input flows, function chainsare generated for the sound, motion, on/off, and manual operationsignal inputs. From Rule 6 of the signal flow morphology, detec-

Simulate Dog(Barking, Kicking,

Digging)

Surface, Human Surface, Human

Human, Electrical Mechanical, Acoustic

Sound, Motion, On/Off,Manual Operation

On/OffVisible Reaction

Fig. 16 Digger Dog black box model

StatusImport

AcousticSense

AcousticProcessStatus


TransferControl

Status Control Control

EE EE EE EESound

Fig. 17 Function chain for the sound signal from a black boxmodel

StatusImportElectro-

magnetic

SenseElectro-

magneticProcessStatus


TransferControl

Status Control Control

EE EE EE EEMotion

Fig. 18 Function chain for the motion signal from a black boxmodel

ControlConvertMech. E.to Control

TransferControl

ConvertHuman E.

to Mech. E.Import

Human E. MEOn/Off MEHEControl Convert

Control toStatus

IndicateStatus

Reaction

ActuateFlowME

Control

ME

Fig. 19 Function chain for the on/off signal from a black boxmodel

ConvertMech. E.to Control

TransferControl

ConvertHuman E.

to Mech. E.Import

Human E. MEManual

OperationHE ME

Control Control

MEActuate

Flow

Fig. 20 Function chain for the manual operation signal from a
black box model
MAY 2008, Vol. 130 / 051101-7


ttarpte

ion

0

Downlo

ion of sound or motion requires the use of a sensor. Sensor func-ional models for detecting sound and motion are generated bypplying the sensor syntax and are provided in Figs. 17 and 18,espectively. To sense sound, acoustic energy must first be im-orted into the system so that it can be sensed with a sense acous-ic energy function block. Motion is detected by first importing

Status

ImportElectrical

StoreElectrical

TransferElectrical

ImportElectro-

magnetic

SenseElectro-

magneticProcessStatus

ImportAcoustic

SenseAcoustic

Status

EE

EE


ConvertHuman E.

to Mech. E.Import

Human E.

ManualOperation

ImportHuman

GuideHuman

ExportHuman

ImportSolid

StabilizeSolid

ExportSolid

Surface

Sound

Motion

User

SupplyElectrical


ConvertHuman E.

to Mech. E.Import

Human E. MEOn/Off

TransferElectrical

TransferElectrical

DistributeElectrical

TransferElectrical

TransferElectrical

TransferElectrical

ConvertElectrical toMechanical

ConvertElectrical toMechanical

M

M

ConvertElectrical to

Acoustic

Tail

Leg

Noise

Fig. 21 Aggregated funct

lectromagnetic energy into the system to be sensed with a sense

51101-8 / Vol. 130, MAY 2008


electromagnetic energy function block. To turn the status signalsgenerated by the sense function blocks into control signals, theprocessor syntax, consisting of a process status function block anda convert status to control function block, is implemented. Controlsignals that can be used to activate the simulation of a Digger Dogare now generated.

DistributeElectrical

ActuateElectrical

ActuateElectrical


TransferControl

tatus Control ControlEE EE EE

TransferControlME

TransferElectrical

TransferControl


IndicateStatus

Reaction

ngeanical

ngeanical

TransferMechanical

TransferMechanical

GuideMechanical

ExportMechanical

GuideMechanical

ExportMechanical

ortstic

IndicateVisual

IndicateVisual

ateitory

al model of a Digger Dog

S

Chaech

Chaech

ExpAcou

IndicAud

The on/off and manual operation signal inputs are switches and



attmrosoavnamsnt

Mtthp

ct2gastemefttisTmfekvee

DtDmD

6

agtlhstftpm

J

Downlo

re modeled following the actuator syntax. The on/off switch, likehe switch building block example in Fig. 10, contains the op-ional user status indicator via position indicator markings. The

anual operation switch, however, does not have a user indicator,elying instead on the simulation to prompt the user of a properperation. Figure 19 provides the subfunction chain for the on/offwitch, and Fig. 20 provides the subfunction chain for the manualperation switch. Both subfunction chains import human energys a means to actuate the switch. The human energy is then con-erted to mechanical energy, which is converted to a control sig-al. The control signal is carried by mechanical energy �1� toctuate the master on/off or �2� to actuate the dog simulation. Theanual operation subfunction chain ends with transfer control

ince there is no user status indication. However, the control sig-al in the on/off subfunction chain is converted to a status that ishen indicated to the user.

5.2.3 Step 3: Aggregate Function Chains Into a Functionalodel. The final step is to aggregate the functional model. During

his phase, subfunction chains are connected and new subfunc-ions may be added. The new functional model will be a compre-ensive model representing the whole, unified functionality of theroduct.

For the Digger Dog example, each of the signal subfunctionhains have been aggregated into the energy and material subfunc-ion chains to create the unified functional model provided in Fig.1. The motion and sound detection have been aggregated to-ether to use the same process status, convert status to control,nd transfer control function blocks. The motion/sound controlignal is then aggregated with the electrical energy function chaino control the flow of electrical energy via an actuate electricalnergy function block in the simulation part of the functionalodel. The manual operation is also used to control the flow of

lectrical energy and is transferred to the same actuate energyunction block in the simulation portion as the motion/sound de-ection signals. The on/off control signal has been transferred intohe master actuate electrical energy function block, and upon leav-ng the master actuate electrical energy function block, the controlignal is converted to a status signal that is indicated to the user.he final signal functions to be added to the aggregated functionalodel are the indicate status function blocks. An indicate visual

unction block has been added to both of the export mechanicalnergy function blocks where one represents a Digger Dog’s legicking and another represents the tail wagging. A final indicateisual function block has been added, leaving the export acousticnergy function block representing the output of the acoustic en-rgy for a Digger Dog barking.

To illustrate how each function-flow pair works in the Diggerog system, the function-flow pairs within the aggregated func-

ional model have been mapped to a component within the Diggerog system. A complete component breakdown including all pri-ary and secondary functionalities can be found on the UMResign Repository.1

ConclusionsThe signal grammars presented address semantic deficiencies ofmodel structure when generating functional models. The signal

rammar, comprised of morphology and syntax, and the Func-ional Basis lexicon provide the nomenclature and structure, al-owing for a more uniform functional modeling. This uniformityelps to ensure the understanding and consistent archival of de-ign information. The addition of carrier flow information aids inhe capturing and archiving of vital system information, allowinguture designers to better understand the original intent and func-ionality of archived product information. Signal usage syntaxrovides templates that can be modified for design intent to createore complete and correct functional models of electromechani-

1
http://function.basiceng.umr.edu/repository


cal products. In particular, the grammars, when combined with theprevious work of Sridharan and Campbell �8�, support manualcreation of functional models through rote application of the rules,given a black box as a starting point. Also, as Sridharan andCampbell have previously shown, the grammars can be integratedinto an automated computer application to generate functionalmodels. Building block examples demonstrate a syntax templateapplication with various common electromechanical components.

Limitations of this work derive mainly from its inductive na-ture. Since all instances of signal 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 con-trol elements that must be represented in order to model electro-mechanical and mechatronic products. Additionally, grammars arenotoriously difficult to implement. This fact can be mitigatedthrough the use of the active center concept from the polymeriza-tion phenomenon �47,48�, as utilized by Sridharan and Campbell�7,8�.

Future work will aim at the integration of grammar into a func-tional modeling CAD package so as to identify discrepancies in afunctional modeling structure. The software package will providethe designer with templates based on the syntax to aid in thefunctional model generation. Also, to validate the uniformity offunctional models when a grammar is employed, case study func-tional models will be generated for electromechanical productswith elements of automation that rely heavily on signal flows foroverall functionality.

References�1� Stone, R., and Wood, K., 2000, “Development of a Functional Basis for De-

sign,” ASME J. Mech. Des., 122�4�, pp. 359–370.�2� 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 Mechanical Design Process, 3rd ed., McGraw-Hill,

New York.�6� Hirtz, J., Stone, R., McAdams, D., and Szykman, S. W. K., 2002, “A Func-

tional Basis for Engineering Design: Reconciling and Evolving Previous Ef-forts,” Res. Eng. Des., 13�2�, pp. 65–82.

�7� Sridharan, P., and Campbell, M. I., 2004, “A Grammar for Functional Struc-tures,” Design Engineering Technical Conferences and Computers and Infor-mation in Engineering Conference, Salt Lake City, UT.

�8� Sridharan, P., and Campbell, M. I., 2005, “A Study on the Grammatical Con-struction of Function Structures,” Artif. Intell. Eng. Des. Anal. Manuf. 19, pp.139–160.

�9� 2005, The New Oxford American Dictionary, 2nd ed., Oxford University Press,New York.

�10� Quirk, R., Greenbaum, S., Leech, G., and Svartvik, J., 1985, A ComprehensiveGrammar of the English Language, Longman, London.

�11� Millward, C. M., 1996, A Biography of the English Language, 2nd ed., Har-court 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. 16.

�14� Fenves, S., 2001, “A Core Product Model for Representing Design Informa-tion,” 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. 243–256.

�16� Miles, L., 1972, Techniques of Value Analysis Engineering, McGraw-Hill,New York.

�17� Otto, K., and Wood, K., 2001, Product Design: Techniques in Reverse Engi-neering, Systematic Design, and New Product Development, Prentice-Hall,New York.

�18� Dieter, G., 1991, Engineering Design: A Materials and Processing Approach,2nd ed., McGraw-Hill, New York.

�19� Little, A., Wood, K., and McAdams, D., 1997, “Functional Analysis: A Fun-damental Empirical Study for Reverse Engineering, Benchmarking and Rede-sign,” Proceedings of the 1997 Design Engineering Technical Conferences,Sacramento, CA, Paper No. 97-DETC/DTM-3879.

�20� Uder, S. J., Stone, R. B., and Tumer, I. Y., 2004, “Function Based Risk As-sessment and Failure Prediction for Unmanned Space Missions,” ASME Inter-national Mechanical Engineering Congress and Exposition, Anaheim, CA,Paper No. IMECE2004-60846.

�21� Lough, K. G., Stone, R. B., and Tumer, I. Y., 2006, “The Risk in Early Design
�RED� Method: Likelihood and Consequence Formulations,” ASME Interna-
MAY 2008, Vol. 130 / 051101-9


0

Downlo

tional Design Engineering Technical Conferences and Computers and Infor-mation in Engineering Conference, Philadelphia, PA.

�22� Moon, S. K., Kumara, S. R. T., and Simpson, T. W., 2006, “Data Mining andFuzzy Clustering to Support Product Family Design,” ASME InternationalDesign Engineering Technical Conferences and Computers and Information inEngineering 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 Withinan Existing Set of Products,” ASME International Design Engineering Tech-nical Conferences, Philadelphia, PA.

�24� Jordan, R. L., Wie, M. V., Stone, R. B., Wang, J., and Terpenny, J., 2005, “AGroup Technology Based Representation for Product Portfolios,” ASME Inter-national Design Engineering Technical Conferences, Long Beach, CA.

�25� Bohm, M., and Stone, R., 2004, “Representing Product Functionality to Sup-port Reuse: Conceptual and Supporting Functions,” Proceedings ofDETC2004, Salt Lake City, UT, Paper No. DETC2004-57693.

�26� Bohm, M., Stone, R., and Szykman, S., 2005, “Enhancing Virtual ProductRepresentations for Advanced Design Repository Systems,” ASME J. Comput.Inf. Sci. Eng., 5�4�, pp. 360–372.

�27� Bohm, M. R., Stone, R. B., Simpson, T. W., and Steva, E. D., 2006, “Intro-duction of a Data Schema: The Inner Workings of a Design Repository,”ASME International Design Engineering Technical Conferences, Philadelphia,PA.

�28� Van Wie, M., Bryant, C., Bohm, M., McAdams, D., and Stone, R., 2005, “AGeneral Model of Function-Based Representations,” Artif. Intell. Eng. Des.Anal. Manuf., 19�2�, pp. 89–111.

�29� Bryant, C., Stone, R., McAdams, D., Kurtoglu, T., and Campbell, M., 2005,“Concept Generation From the Functional Basis of Design,” InternationalConference 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,”ASME International Design Engineering Technical Conferences and Comput-ers 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 DesignTool,” ASME International Design Engineering Technical Conferences andComputers 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,”ASME 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,” ASME Interna-
51101-10 / Vol. 130, MAY 2008


tional Design Engineering Technical Conferences and Computers and Infor-mation in Engineering Conference, Philadelphia, PA.

�34� Galvao, A. B., and Sato, K., 2006, “Incorporating Affordances into ProductArchitecture: Methodology and Case Study,” ASME International Design En-gineering Technical Conferences, Philadelphia, PA.

�35� Park, J., and Simpson, T. W., 2005, “An Activity-Based Costing Method forProduct Family Design in the Early Stages of Development,” ASME Interna-tional Design Engineering Technical Conferences, Long Beach, CA.

�36� Stone, R. B., Tumer, I. Y., and Wie, M. V., 2005, “The Function-Failure De-sign Method,” ASME J. Mech. Des., 127�3�, pp. 397–407.

�37� Bohm, M., Stone, R. B., and Szykman, S., 2002, “Decomposition-Based Fail-ure Mode Identification Method for Risk-Free Diagram in Large Systems,”ASME J. Mech. Des., submitted.

�38� Hutcheson, R. S., McAdams, D. A., Stone, R. B., and Tumer, I. Y., 2006, “AFunction-Based Methodology for Analyzing Critical Events,” ASME Interna-tional Design Engineering Technical Conferences and Computers and Infor-mation in Engineering Conference, Philadelphia, PA.

�39� Nagel, R. L., Stone, R. B., and McAdams, D. A., 2006, “A Process ModelingMethodology for Automation of Manual and Time Dependent Processes,”ASME International Design Engineering Technical Conferences and Comput-ers and Information in Engineering Conference, Philadelphia, PA.

�40� Nise, N. S., 2004, Control Systems Engineering, Wiley, New York.�41� Chen, D., and Törngren, M., 2004, “A Systematic Approach for Identifying

Operational Relationships in Embedded Computer Control Systems,” EURO-MICRO Conference, Rennes, France.

�42� Chen, L., Jayaram, M., and Xi, J. F., 2002, “A New Functional RepresentationScheme for Conceptual Modeling of Mechatronic Systems,” Design Engineer-ing Technical Conferences and Computer and Information in EngineeringConference, Montreal, Canada.

�43� Jayaram, M., Chen, L., and Xi, J. F., 2003, “Functional Modeling of ComplexMechatronic Systems,” Design Engineering Technical Conferences and Com-puter and Information in Engineering Conference, Chicago, IL.

�44� Rajan, J. R., 2002, “A Robust Functional Modeling Method in Product De-sign,” M.S. thesis, The University of Texas at Austin, Austin, pp. 73–135.

�45� Rajan, J. R., Stone, R. B., and Wood, K. L., 2003, “Functional Modeling ofControl Systems,” International Conference on Engineering Design, Stock-holm.

�46� Gemmy Industries Corporation, Digger Dog �www.gemmy.com�.�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 Sci-

ence, Wiley, New York.



A Signal Grammar to Guide Functional Modeling of ......• Grammar: the whole system and structure...

Documents

Transcript of A Signal Grammar to Guide Functional Modeling of ......• Grammar: the whole system and structure...