B-CUBE MODEL IN AUTOMATED FUNCTIONAL DESIGN

Vicente Chulvi and Rosario Vidal

GID, Departament d’Enginyeria Mecànica i Construcció, Universitat Jaume I, Av. Sos Baynat, Castellón, Spain

Keywords: Knowledge Based Systems, Functional design, Ontologies.

Abstract: The present work proposes to use both the NIST’s functional basis and the B-Cube model in the

development of a KBS that is capable of automating functional design. For this purpose this article shows

with an example how the system will work using the FBS framework. The starting point is defended by the

terms of NIST functional basis. The evolution from functions to structures, that is, to the solution, is

achieved by means of B-Cube model in the behaviour layer.

1 INTRODUCTION

Automated design is a current topic in most

significant companies around the world and even

more so in high technology companies, such as in

the automotive or aerospace industries (Kochan,

1999; Liening and Blount, 1998). The last decade

has witnessed the gradual introduction of automated

design technologies into other manufacturing fields,

with techniques like DFx (Design For Assembly,

Design For Environments, etc.) or KBS (Knowledge

Based Systems). Several authors have written on the

advantages of these technologies (Bermell-García et

al., 2001; Vidal and Mulet, 2006; Sainter et al.,

2000; Chen, 1999).

Functional design is presented as a key step in

the product design process and, as such, it is the

focus of the main scientific efforts being made to

automate design in artificial intelligence (AI)

systems. The starting point of functional design is

the concept of function, behaviour and structure.

Although these concepts have been used for a long

time, it was only in 1990 when they were clearly

defined and when they were proposed as a

modelling and representing framework, due to their

functionality (Gero, 1990; Umeda et al., 1990). The

FBS framework can be applied as a methodology for

design process analysis, representing the evolution

of the design state from protocol studies (Takeda et

al., 1994). Within this framework, function

represents the duties that the design fulfils, structure

represents the physical elements of the solution and

behaviour is the link between F and S. In solution

synthesis, behaviour derives from a particular

function, and the solution is achieved through this

behaviour. Furthermore, when a solution has been

defined, behaviour is inferred from that solution in

order to evaluate whether the solution reaches the

required degree of functionality.

The FBS framework allows computational

modelling to be carried out. Thus, several authors

have attempted to develop approaches and software

applications to implement FBS-based procedures

(Qian, 2002) or to model function and/or structure

libraries to be implemented in functional reasoning

processes (Lossack et al., 1998; Bracewell and

Sharpe, 1996; Ying-Chieh et al., 2000; Chakrabarti

et al., 2002; Lossack, 2002; Campbell et al., 2003).

The possibilities of these systems have been

increased by the use of taxonomies and ontologies.

Ontologies (and taxonomies consequently) can

be understood as a form of knowledge

representation. A taxonomy consists of a group of

concepts and relationships that are organised

hierarchically and whose concepts can be arranged

as classes with sub-classes (Gilchrist, 2003). Several

function taxonomies have been developed, but the

most significant reconciliation of function

taxonomies nowadays are those provided by the

National Institute of Standards and Technology

(NIST) (Hirtz et al., 2002). The NIST’s functional

basis is a reconciliation and integration of other

taxonomies, mainly from research carried out by the

NIST (Szykman et al., 1999) and the functional

basis effort (Stone and Wood, 2000), the purpose of

which was to facilitate the development of a formal

representation of functions with a hierarchical

vocabulary of standardised terminologies, focused

on mechanical design.

190

Chulvi V. and Vidal R. (2010).

B-CUBE MODEL IN AUTOMATED FUNCTIONAL DESIGN.

In Proceedings of the 2nd International Conference on Agents and Artiﬁcial Intelligence - Artiﬁcial Intelligence, pages 190-196

DOI: 10.5220/0002702001900196

 SciTePress

An ontology can be described as an explicit

specification of a shared conceptualisation, where

concepts and relations are organised hierarchically

and concepts are classified as classes and instances.

Ontologies can be taxonomically or axiomatically

based (Gruber, 1993). The B-Cube model (Chulvi

and Vidal, 2009) is an ontology for the behaviour

layer mainly based on the DOLCE’s meta-ontology

(Masolo et al., 2003; Ferrario and Oltramari, 2005),

which uses three-dimensional vectors as terms. Each

dimension of these vectors defines one characteristic

of the behaviour, so this model uses definitions to

define behaviours instead of one single word.

The aim of this article is to show how both the

NIST’s functional basis and the B-Cube model can

work together to develop a KBS that is capable of

automating the functional design. Section 2

introduces the B-Cube model developed by the

authors, while section 3 uses an example to show the

theoretical work of the proposed KBS. The article

ends with some conclusions in section 4.

2 B-CUBE

The B-Cube model is used to represent the

behaviour layer in the functional design process

within the FBS framework. This model proposes a

three-dimensional scheme that uses definitions as

behavioural concepts. The key to this approach is

that a behaviour is not defined with a word or a

taxon, which could cause ambiguity and

misinterpretation, but rather it is defined as a three-

dimensional vector (X, Y, Z) that is set by its

characteristics and qualities.

The starting point from which to define these

parameters is the DOLCE’s upper-level ontology.

The definitions of the DOLCE have been slightly

adapted to meet B-Cube’s purposes. Endurant is

defined as the entity or element (Structure) to which

the B-Cube entry refers. It is supposed that there are

an infinite number of endurants in the universe and

they are differentiated as being physical (PEDs) and

non-physical endurants (NPEDs). Perdurant (P) is a

characteristic that defines a behaviour and it refers to

the kind of behaviour that affects the above-

mentioned entity. Ps are situated on the Y axis of the

B-Cube model. Lastly, qualities are defined as

characteristics linked to other entities which are

going to be used to define the behaviour. There are

three different sorts of qualities: temporal (TQs),

physical (PQs) and abstract qualities (AQs). TQs

are directly related to Ps, so they will be used to

define a Behaviour, and are located on the Z axis.

The B-Cube model is completed with the X axis,

where the PQs will be, if the entry to the model was

a PED, and the AQs, if the entry was an NPED.

Despite the fact that numerical values are used when

working with the B-Cube model, all of these values

have a term to define them. The terms have been

taken mainly from the DOLCE’s terminology

(Masolo et al., 2003) and increased by Garbacz’s

work on it (Garbacz, 2006). As these terms were not

enough to meet the needs of B-Cube, they were

fulfilled with terms from Rasmussen’s taxonomy

(Rasmussen, 1983) and the NIST classification of

flows (Hirtz et al., 2002, Nagel et al., 2007). As a

result, they are defined as shown in Table 1.

Figure 1: B-Cube model.

3 DESIGN REPRESENTATION

MODEL BASED ON B-FES

The design representation model used to represent

the knowledge in this project pretends to be useful

for the understanding, transferring, and reproduction

of this knowledge. There are a lot of methodologies

created with the aim to represent the information and

transfer it to computer systems to be integrated into

a KBS. The IDEF language family consists in a set

of modelling languages within the field of system

engineering, which cover a wide range of needs

from information’s capture and modelled to net

design. Due to their diversity they present a huge

number of terminologies and symbols in order to

represent knowledge. So it doesn’t consist on

choosing the best tool, but it is about choose the

most adequate in the right moment. Several works

have taken advantage from this adaptability, and

they have create their own approaches to this

modelled language using the standardized

terminology (Kim and Jang, 2002, Romero et al.,

2008). The proposal here applied is based on IDEF4,

and it is adapted to represent the knowledge within a

B-FES framework using both Functional basis and

B-CUBE MODEL IN AUTOMATED FUNCTIONAL DESIGN

191

Table 1: Values of B-Cube model with examples.

Axis Value Term Significance Examples

1 Spatial location Position of a PED in space To move an object

2 Topological

connectedness

The kind of connection at a topological level in which a

PED finds itself

To break an object

To join an object

3 Energy Energetic state of a PED To freeze water

To charge a battery

4 Magnitude A physical magnitude of the PED that is affected by the

behaviour

To increase weight

To change colour

5 Signal Actions referred to PEDs when they act as signals To increase a wave

A mobile phone sending a signal

-1 Skill The behaviour does not require conscious control by

the subject

Driving a car

Playing the piano

-2 Rule The behaviour requires conscious control by the

subject, but this is subject to some process or “written

rule”

Cooking following a recipe

To tune an instrument

-3 Knowledge The behaviour requires conscious control by the

subject, and this is not subject to any process or

“written rule”

To compose a symphony

To manage an enterprise

1 Process The behaviour is cumulative and non-homeomeric To run

2 State Cumulative and homeomeric To sit

3 Accomplishment Non-cumulative and non-atomic To give a lecture

4 Achievement Non-cumulative and atomic To break a glass

1 Initial SoA The behaviour makes the initial PQ or AQ decrease or

disappear

To cool an object

2 Immutable SoA The behaviour doesn’t vary the grade or quantity of PQ

or AQ affected by it

To convert energy

3 Final SoA The behaviour makes the grade or quantity of PQ or

AQ increase or appear

To warm an object

B-Cube model’s terminologies. It pretends to

achieve an intuitive and easy to understand

representation for any designer. The figure 2 shows

the boxes used to represent functions, behaviours,

structures and restrictions (structures that belong to

environment, not to design), and the main

interactions between them.

Figure 2: Representation boxes.

4 DISCUSSION

In an ideal system the designer would only need to

introduce what he wants to design and the system

would provide him with the best solution or several

optimal solutions. This proposed ideal KBS needs a

proper semantic tool, databases and evaluation

system tool, besides the FBS-based design system,

which has the B-Cube model as its core. As this

section aims to show how the B-Cube model can

work within the system, we are going to suppose

that both the semantic tool and the evaluation system

work ideally (or they are controlled directly by the

designer) and that there are complete databases for

the desired purpose. The NIST’s functional basis

will be used to complete the function level.

The example developed for this purpose shows

the development of the design of a device for writing

and erasing (signs) on paper that can be used by one

person and put easily in your lapel. In this case the

designer or the semantic tool can distinguish four

functions: write, erase, handle, and hold; and the

restrictions corresponding to the environment level:

person, hand, lapel, paper, and signs. Functions have

been adapted to NIST terminology in order to

standardise them. So, the function “write” can be

interpreted as connecting signs with the paper, so it

ICAART 2010 - 2nd International Conference on Agents and Artificial Intelligence

192

corresponds to the term “couple” of the functional

basis. The function “erase”, which has the opposite

meaning to “write”, can be defined as “remove”. In

turn, the fact that an object is held can correspond to

the terms “secure” and “(not) allow degree of

freedom”. Despite the fact that it seems that only

one term must be chosen, it will be shown below

how it is advisable to indicate the two options.

Lastly, the function “handle” corresponds to the

terms “translate” and “rotate”.

A correlation between the terms used by the

functional basis and those used by the B-Cube

model was created to enable the behaviour level to

be obtained from the function level. From this

correlation it can be seen that the function “couple”

corresponds to the behaviour (2,1,3). That is, X=2,

that means that the behaviour affects the topological

connectedness; Y=1, the behaviour represents a

process that acts in a cumulative and non-

homeomeric way; and Z=3, that represents that the

topological connectedness is achieved by means of

the behaviour. “Remove” can be represented by

behaviours (1,1,1), (1,3,1), (2,1,1), (2,2,1), so a

better definition is also required from the semantic

tool, from the designer’s feedback or from any other

automated system (e.g. algorithm libraries). In this

case we chose (2,1,1), as it acts as the opposite of

(2,1,3), which was unambiguously defined. The next

function can be defined both for “secure” and “(not)

allow degree of freedom”. Here, the first definition

has a correspondence with the terms (1,2,2), (2,1,3),

and (2,3,2), while the second one corresponds to

(1,2,2). This value is chosen to represent the

behaviour since it is the only value that matches the

two possible functions. Lastly, functions “translate”

and “rotate” only correspond to the term (1,1,2).

These behaviours, together with their relations

with the environment level, are the starting point to

define the structures that are needed for the desired

design. For the development of this example it has

been supposed that the available structure database

is sufficient but limited. In this case, the objective

consists in searching in the database for the

structures that are able to carry out the required

behaviour. Then the interaction with these structures

with the environment’s restrictions is considered in

order to obtain a first selection and, finally, the

remaining solutions are evaluated in order to

determine which ones can really be carried out and

under which conditions. Tables 2 and 3 show the

examples of the search for structures-solution for

behaviours (2,1,3) and (2,1,1).

It can be observed in the example in Table 2 that

five structures capable of carrying out behaviour

(2,1,3) were found in the database. Two of these

structures were rejected straight away because of

their effects on the restriction, that is, they damage

the paper. The remaining three were evaluated on

the basis of their final purpose. As can be observed,

two of them present one disadvantage and one

requirement, and the other one presents three

disadvantages and one requirement. So, this last one

is rejected. As the other two options seem to be

equally good, the system is split into two from now

on and two different final solutions will be

developed and then evaluated at the end of the

process. The evolution from carbon lead is named

“design A”, and the ink one is named “design B”.

Table 2: Structure search and evaluation from behaviour

(2,1,3).

Structure Compatibility

with paper

Evaluation

Carbon lead Good It wears down. It requires a

container.

Ink Good It wears down. It requires a

container. It gets dry with

air contact.

Chalk Good It wears down. It requires a

container. Poor trace

quality. It marks and

smudges.

Carving Bad -

Welding Bad -

Table 3: Structure search and evaluation from behaviour

(2,2,2).

Structure Compatibilit

y with ink

Evaluation

Hood:

- Metal

- Plastic

- Wood

- Cardboard

Good It must be removable.

- Viable

- Viable. Ecological.

Low mechanical

strength. Ink can soak

through it.

Cover

Good Non-viable. It is not

removable

Gel Bad -

Vacuum Good Very expensive system

Difficult to implant

into a small device.

Next evaluation phases must take this split into

account. So, the next structure’s evaluation

considers the structure’s utility with both carbon

lead and ink. As an example, for the search and

evaluation from behaviour (2,1,1), the structure

“rubber” is the only one that has a good

compatibility with paper. This structure is useful

B-CUBE MODEL IN AUTOMATED FUNCTIONAL DESIGN

193

within design A, but it is useless in design B. In this

case a structure with regular or dubious

compatibility must be chosen as a solution in design

B. The selected structure is again the one with the

lowest number of disadvantages or requirements.

Figures 3a and 3b show the differences in this first

step in the development of designs A and B.

The system now evolves from this first step by

turning the disadvantages and requirements of the

new structures into new behaviours, which can be

carried out by the existing structures or new ones

may be required. The existing structure will always

be preferred to a new one since no new behaviours

will be needed and the number of structures will be

lower. So, the new structures “carbon lead” and

“ink” generate two new behaviours: one to show that

they wear down (4,2,1) and the other one to show

the need to be contained (2,2,2). Hence, behaviour

(4,2,1) is derived from behaviours (2,1,3) and

(2,1,1), which correspond to normal device use. As

it proceeds from a disadvantage, it is considered as a

non-desirable behaviour and it will need to be

considered differently to the other behaviours. On

the other hand, behaviour (2,2,2) proceeds from a

requirement, so it is considered as a desirable

behaviour and it will be treated in the same way as

the behaviours that come from functions.

Figure 3a: First step in the evolution of design A.

If we centre on case B, the structure “ink” has

generated a non-desirable behaviour. Here, a new

behaviour has to appear in order to solve the

Figure 3b: First step in the evolution of design B.

requirement of the non-desirable behaviour, whose

object is the “ink”, and it will need a new structure

able to carry out this new behaviour (Table 3)

The development of the designs will evolve in the

way described until all the required behaviours can

be carried out by some existing structure and all the

existing structures need no new, as yet undefined,

behaviours. At this point, the design process is

considered to have ended and all the designs are

ready to be evaluated, both by the designer and by

an external application built for this purpose. The

development of the design B obtained in this

example is represented in Figure 4.

5 CONCLUSIONS

In this paper the authors have defended the use of

both the NIST’s functional basis and the B-Cube

model for developing a KBS that is capable of

automating functional design. The B-Cube model is

shown as one of the tools that are needed to create a

KBS to automate the design process within an FBS

framework. The importance of behaviour lies in its

concreteness (in contrast to the generality of

function) and also in its direct relation with

structures. For this purpose, the B-Cube model

offers the advantages of the lower ambiguity of

vectors compared to taxa and the facility of

computer programs to work with vectors. It has also

proved

its ability to work well with the NIST’s

ICAART 2010 - 2nd International Conference on Agents and Artificial Intelligence

194

Figure 4: Final design B result.

functional basis, which is considered to be the most

useful correlation of function terms, as well as being

suitable for automated functional design.

As well as the B-Cube model and the NIST’s

functional basis, complete databases and evaluation

and semantic tools are also needed to automate the

design process. The use of ontologies is the easiest

way to interact with these tools and share the

knowledge in an appropriate manner. Future work

will be directed along these lines, with emphasis on

both the structures level and the link between

functional design and Computer Aided Inventing

(CAI) tools in order to innovate and improve the

design process.

ACKNOWLEDGEMENTS

The authors would like to acknowledge the Ministry

of Education and Science in Spain (ref. DPI2006-

15570-C02-00) and the European Fund for Regional

Development (FEDER) for their funding.

REFERENCES

Bermell-García, P., Fan, I.-S., Li, G., Porter, R. & Butter,

D., 2001. Effective abstraction of engineering

B-CUBE MODEL IN AUTOMATED FUNCTIONAL DESIGN

195

knowledge for KBE implementation. 13 International

Conference on Engineering Design. Glasgow.

Bracewell, R. & Sharpe, J., 1996. Functional Descriptions

used in Computer Support for Qualitative Scheme

Generation-"Schemebuilder". AIEDAM, 10, 333-346.

Campbell, M., Cagan, J. & Kotovsky, K., 2003. The A-

Design Approach to Managing Automated Design

Synthesis. Research in Engineering Design, 14, 12-24.

Chakrabarti, A., Langdon, P., Liu, Y. & Bligh, T., 2002.

An Approach to Compositional Synthesis of

Mechanical Design Concepts using Computers. In

Chakrabarti, A. (Ed.) Engineering Design Synthesis.

Understanding, approaches and tools. London,

Springer-Verlag.

Chen, Y. M., 1999. Integrating Knowledge, Data and

Geometry: A Computer-Aided Concurrent

Engineering Infrastructure. Integrated Computer-

Aided Engineering, 6, 189-212.

Chulvi, V. & Vidal, R., 2009. Functional basis and B-

Cube: alternative or complementary models?

International Conference On Engineering Design,

ICED'09. 24-27 August. Stanford, Ca, USA.

Ferrario, R. & Oltramari, A., 2005. Towards a

Computational Ontology of Mind.

Garbacz, P., 2006. Towards a standard taxonomy of

artifact functions. Applied Ontology, 1, 221-236.

Gero, J. S., 1990. Design prototypes: A knowledge

representation schema for design. AI magazine, 11, 26-

36.

Gilchrist, A., 2003. Thesauri, taxonomies and ontologies –

an etymological note. Journal of Documentation, 59.

Gruber, T. R., 1993. Toward Principles for the Design of

Ontologies Used for Knowledge Sharing. In K. A.

(Ed.) Padova, Italy, Knowledge Systems Laboratory,

Stanford University.

Hirtz, J., Stone, R., Mcadams, D., Szykman, S. & Wood,

K., 2002. A functional basis for engineering design:

Reconciling and evolving previous efforts. Research

in Engineering Design, 13, 65 - 82.

Kochan, A., 1999. Jaguar uses knowledge-based tools to

reduce model development times. Assembly Automation,

19, 114-117.

Liening, A. & Blount, G. N., 1998. Influences of KBE on

the aircraft brake industry. Aircraft Engineering and

Aerospace Technology, 70, 439-444.

Lossack, R., 2002. Design Process and Context for the

Support of Design Synthesis. In Chakrabarti, A. (Ed.)

Engineering Design Synthesis. Understanding,

approaches and tools. London, Springer-Verlag.

Lossack, R., Umeda, Y. & Tomiyama, T., 1998.

Requirement, Function and Physical Principle

Modelling as the basis for a Model of Synthesis.

Computer Aided Conceptual Design'98.

Masolo, C., Borgo, S., Gangemi, A., Guarino, N. &

Oltramari, A., 2003. WonderWeb Deliverable D18.

Laboratory For Applied Ontology-ISTC-CNR.

Nagel, R. L., Bohm, M. R., Stone, R. B. & Mcadams, D.

A., 2007. A representation of carrier flows for

functional design. 16th International Conference on

Engineering Design. 28-30 August Paris, France.

Qian, L., 2002. Creative Design by Analogy. In

Chakrabarti, A. (Ed.) Engineering Design Synthesis.

Understanding, approaches and tools. London,

Springer-Verlag.

Rasmussen, J., 1983. Skills, rules, and knowledge;

Signals, signs and symbols, and other distinctions in

human performance models. IEEE Transactions on

systems, man, and cybernetics, SMC-13, 257-266.

Sainter, P., Oldham, K. & Larkin, A., 2000. Achieving

benefits from knowledge-based engineering systems in

the longer term as well as in the short term. ICE 2000,

Proceedings of the 6th International Conference on

Concurrent, 143-150.

Stone, R. B. & Wood, K. L., 2000. Development of a

Functional Basis for Design. Journal of Mechanical

Design 122, 359-371.

Szykman, S., Racz, J. & Sriram, R., 1999. The

representation of function in computer-based design.

Design Engineering Technical Conferences.

September 12-15, 1999, Las Vegas, Nevada, ASME.

Takeda, H., Yoshioka, M., Tomiyama, T. & Shimomura,

Y., 1994. Analysis of design processes by function,

behaviour and structure. The Delft Protocols

Workshop, conference proceedings.

Umeda, Y., Takeda, H., Tomiyama, T. & Yoshikawa, H.,

1990. Function, behaviour, and structure. In Gero, J.

(Ed.) Applications of Artificial Intelligence in

Engineering V. Berlin, Springer.

Vidal, R. & Mulet, E., 2006. Thinking about Computer

Systems to support design synthesis. Communications

of the ACM, 49, 100-104.

Ying-Chieh, L., Chakrabarti, A. & Bligh, T., 2000. A

computational framework for concept generation and

exploration in mechanical design. Artificial

Intelligence in Design'00.

ICAART 2010 - 2nd International Conference on Agents and Artificial Intelligence

196