implies that the file referenced by FileName is processed, including its lines in the position of the original file where the construct #use is found. This constructs can be arbitrarily combined in an XFL file.

The most relevant characteristic of the way in which universes of discourse and membership functions are defined (what is called type definition) in XFL is the support for inheritance mechanisms. These mechanisms are intended to simplify the specification of complex system and to ease module reuse.

A type definition in XFL has the following format:

type Identifier : BaseType {

MembershipFunction

MembershipFunction

...

}

Where BaseType contains a reference to the type (or types) from which the defined type derives. This reference can be done to a predefined type or to any type whose definition has been already made in the specification.

XFL provides two predefined types: integer and real. When a type definition uses one of this predefined types, BaseType takes the form:

PredefinedType [ Cardinality ] ( Range )

Where Range are the values defining the universe of discourse for the variables of this type. It is specified by means of two numerical values with a < character as separator. Cardinality is an optional parameter that can be used to specify the number of distinct values that are going to be considered in the universe of discourse for a variable of this type. For integer types it defaults to the number of integers in the defined range, while for real variables a default value (currently, 256) is assumed when not explicitly specified. Cardinality is used in applications such as the synthesis of digital hardware (it defines the number of bits to be used for the variables) or the implementation of defuzzification methods when calculating the step size for exploring the universe of discourse.

If the type being defined is a derived type, BaseType may contain a list of previously defined type identifiers (separated by commas), with the only restriction that all of them must finally derive from the same predefined type. The derived type has the range obtained from the intersection of its ancestor ranges and the lowest cardinality defined for them. A derived type inherits automatically all the membership functions defined by its ancestors, with the following precedence rule for the cases in which one function appears in more than one parent type: the definition corresponding to the last type in the ancestor list is used.

Membership Functions

The definition of a new membership function (or the overloading of a previously defined one for a derived type) corresponds to a construct of the form:

Identifier FunctionClass ( PointList )

Where PointList contains values for the points relevant for defining the function, according to the class specified by FunctionClass. These values have no other constraint that those required by class coherence and that the function must take at least a non-zero value inside the universe of discourse. The supported membership function classes are:

	triangle	PointList corresponds to the three points defining the triangle (basis, apex, basis). At the basis points the function takes a zero value, while at the apex the value of the function is 1
	rectangle	PointList corresponds to a pair of values defining an interval in which the function takes the value 1, while out of this interval the value is zero
	trapezoid	PointList corresponds to four values defining a trapezoid (major basis, minor basis, minor basis, major basis). Between the points of the minor basis the function takes the value of 1, while at the points of the major basis the value is zero
	bell	PointList defines two values, a and b. The value of the function in any point x is given by exp(-((x-a)/b)**2)
	sigma	PointList defines two values, a and b. The value of the function in any point x is given by 1/(1+exp(x-a)/b)
	delta	Takes a zero value in the whole universe of discourse, except at one point (identified by PointList) where it takes the value 1
	points	Defines a linear approximation to an arbitrary function. PointList takes an special format, in which each element of the list is a pair of numerical values separated by the character :. The first value corresponds to a point in the universe of discourse and the second to the value of the function at that point. Between each pair of two successive points the function is defined by the line that joins them.

As an example, here is a definition for some types and a plot of the corresponding membership functions:

type X : integer (0<100){ LE trapezoid (-25,0,10,35) LC triangle (30,40,50) CE triangle (45,50,55) RC triangle (50,60,70) RI trapezoid (65,90,100,125) }
type TrAng : integer (-90<270) { RB triangle (-100,-45,10) RU triangle (-10,30,60) RV triangle (50,70,90) VE triangle (80,90,100) LV triangle (90,110,130) LU triangle (120,150,190) LB triangle (170,225,280) }
type Wheels : integer (-30<30) { NB triangle (-43,-30,-17) NM triangle (-25,-15,-6) NS triangle (-12,-6,0) ZE triangle (-6,0,6) PS triangle (0,6,12) PM triangle (6,15,25) PB triangle (17,30,43) }

Rulebase Definition

The basic element in the definition of the rulebase controlling the behavior of a fuzzy system in XFL is called a module. Each module has a set of variables (for input and output) and an specification of its structure. In general terms, a module definition has the form:

Identifier ( VariableList )

ModuleStructure

Where the identifier allows further references to the module in some other (compound) module. XFL requires specifications to define a module called system, which specifies the global behavior of the system and whose input/output variables are those of the whole fuzzy system. Each of the variables in a module are defined in VariableList by means of:

TypeIdentifier ? Identifier

for inputs and:

TypeIdentifier ! Identifier

for outputs.

The identifier will be used in any reference to the variable inside the module, while TypeIdentifier defines the type of the variable.

As previously stated, XFL allows the definition of rulebases of an arbitrary (complex) structure. This feature is supported by the specification of module structrures. There are two different ways for this specification: a set of rules can be defined, or the module can be defined in terms of a set of composed modules. For a module whose structure is defined in terms of a set of rules ModuleStructure is:

rulebase {

Rule

Rule

...

}

While for a module whose structure is defined in several interconnected modules, ModuleStructure takes the form:

components { ModuleReferences }

Each individual rule has the following structure:

if Antecedent -> Consequent

The antecedent of a rule is an arbitrary combination of expressions associating any of the input variables to any of the membership functions defined for its type. Each of these expressions is of the form:

VariableIdentifier is MembershipFunctionIdentifier

The operators combining the expressions in the rule antecedent are identified by:

• The character ~ for the not operator.
• The character & for the and operator.
• The character | for the or operator.

The usual rules for associativity, distributivity and precedence hold. As usual, expressions can be grouped by means of parenthesis.

The consequent of a rule is made of a list (comma separated) of expressions associating any of the output variables to any of the membership functions defined for its type.

As an example, consider the following table defining the behavior of a system with two inputs and one output, using the membership functions that appear in the previous example:

The definition of this behavior in XFL is done by a system module with the following structure:

system (X ? vx, TrAng ? ta, Wheels ! wa)

rulebase {

...

}

Cells in the upper right corner correspond to the following rule:

if ((vx is RC | vx is RI) &

(ta is RB | ta is RU)) |

(vx is RI & ta is RV) -> wa is PB

and those in the lower left corner correspond to:

if (vx is LE & ta is LV) |

((vx is LE | vx is LC) & (ta is LU | ta is LB)) -> wa is NB

When the structure of a module is defined in terms of the composition of a set of other modules, this definition consists of an arbitrary combination of references to the components modules connected by means of the composition operators:

• Parallel, noted with the symbol []
• Serial, with the symbol ;

A reference to a module is made by including its identifier and instantiating its input/output variables to input/output variables in the parent module or to dummy interconnection variables in the case of serial composition.

The following rules apply for the semantics of module composition:

• Modules composed using parallel mode does not share any constraint and model the decomposition of the parent module in simpler elements. Two parallel composed modules can share input variables (which are processed independently by each module) but never output variables.

• Modules composed using serial mode share at least one variable: output from the first and input to the second. In this context we can refer to dummy interconnection variables linking the two modules, since it is not possible to use variables instantiated from the parent module when serially composing the modules.

• The association with the instantiated parent module variables and the link between dummy variables is made implicitly by name. The obvious rules enforcing compatibility in types and modes (input/output) are applied. Input variables to the parent modules can be freely used as input variables to any number of component modules, while each output variable from the parent module can be only instantiated by one component module.

• All the variables in a component module must be bound either to parent module variables or by means of a dummy linking in serial mode composition.

• The component module structure is arbitrary, taking into account that:
  • Serial composition takes higher precedence than parallel.
  • Parallel composition is distributive with respect to serial.
  • Both operators are associative. Serial composition is not, obviously, commutative.
  • Module composition can be grouped by means of parenthesis. Any of these structures built must, of course, follow the rules described above.

Here is, as example, the structure in terms of module compositions for the hierarchical rulebase shown previously:

Primary (tI1 ? pi1, tI2 ? pi2, tI3 ? pi3, tD0 ! po)

rulebase {

...

}

Secondary1 (tD0 ? s1d, tI1 ? si1, tI2 ? si2, tO1 ? so1)

rulebase {

...

}

Secondary2 (tD0 ? s2d, tI2 ? si2, tI3 ? si3, tO2 ? so2)

rulebase {

...

}

system (tI1 ? I1, ti2 ? I2, tI3 ? I3,

tO1 ! O1, tO2 ! O2)

components {

Primary (I1, I2, I3, D0) ;

(Secondary1 (D0, I1, I2, O1) []

Secondary2 (D0, I2, I3, O2))

}

Although fuzzy operations definition is outside of the scope of XFL, the mechanisms for it play a fundamental role in the use of the language by any fuzzy system development tool. Essentially, any tool able to translate an XFL specification into an appropriate implementation format should use a configuration method to define (in terms of the target language) the fuzzy operations that can be used. An XFL-based tool should support mechanisms for identifying these operations, so it can produce a complete implementation of the source specification. This section introduces the mechanism in use by the currently available tools, which is general and flexible enough to be extended to any target language.

In the current generation of XFL-based tools, fuzzy operations are selected to be used in an implementation by a series of directives included in the source file. These directives identify an operation definition in the configuration file used by the tool. These directives are:

• #and, which selects the T-norm to be used as operator and.

• #or, which selects the T-conorm to be used as operator or.

• #not, which selects the implementation for the operator not.

• #implication, which selects the implication function.

• #composition, which selects the T-conorm used as preaggregation method (operator c).

• #also, which selects the T-conorm used as aggregation operation of the output membership function (operator also).

• #defuzzification, which selects the defuzzification method.

Each of these directives uses an identifier, corresponding to the keyword for the operation definition in the configuration file for the tool. XFL-based tools should supply a set of default values for each operations.

As previously noted, the case of the #composition directive is a little subtle: if there is no such directive in a source file, rule preaggregation is simply not used.

The Configuration File

The configuration file consists of a set of sections, each one corresponding to a class of the defined elements, and marked by an start and an end symbol. Comments, as in XFL, are initiated by the symbol //. Start symbols are:

• %Tnorm (#and directive).

• %Tconorm (#or, #composition and #also directives).

• %Negation (#not directive).

• %Implication (#implication directive).

• %Defuzzification (#defuzzification directive).

• The end symbol is made of the characters %%

Inside each section, the definition of operations has two parts: the operation identifier (in a separate line), and the body of the definition, included below its identifier in subsequent lines that must start with a tab character. Any definition body (either simple operations or defuzzification methods) may include lines with sentences of the target language, using the following constructs:

• %proc, to define procedures or functions more complex that those allowed by the mechanisms provided for building the body and that must be called from it.

• %data, to define data structures used by either the standard mechanisms or those specified using the construct above.

• %end, to mark the end of either a %proc or %data construct.

The body of an operation definition (apart from the case of the defuzzification methods, which use an special format) must contain the body of a native construct of the target language (function, procedure, macro, etc.) returning the result of the operation.

For binary operations, the first operand is identified by _a and the second by _b. For unary operators (in fact, for negations), the only operator used is noted by _a.

As an example, here is a partial listing of the configuration file included into the Xfuzzy distribution:

%Tnorm

prod ((_a)*(_b))

min ((_a)>(_b)?(_b):(_a))

. . .

%%

%Tconorm

max ((_a)>(_b)?(_a):(_b))

. . .

disjoint_sum (delta(_a,_b))

%proc

FUZZY delta (a, b) FUZZY a,b; {

FUZZY x, y;

x = a > (1-b) ? 1-b : a;

y = b > (1-a) ? 1-a : b;

return x > y ? x : y;

}

%end

%%

%Implication

min ((_a)>(_b)?(_b):(_a))

prod ((_a)*(_b))

Diene ((1-(_a))>(_b)?1-(_a):(_b))

. . .

%%

Note the use of a %proc construct to implement a little more complex calculation for an operation inside the %Tconorm section.

Defuzzification Methods

The definition of a defuzzification method is more complex than the other operations: the definition body lines are preceded by symbols indicating the requirements imposed by the method on the membership functions for being applicable, and the point of the defuzzification process in which the contents of the lines are used. These symbols are:

• %requires, followed by a comma separated list of membership functions classes (as defined by XFL) for which this method is applicable. If this symbol is not used, the method is applicable for any class.

• %init, which marks the start of the target language lines used for variable initialization.

• %exit, which marks the start of the target language lines used at the end of the process for assigning the final output value.

• %numloop, which indicates that the lines below are going to be executed in a loop through the universe of discourse for the variable. Inside this loop the value of the variable and the value of the global output membership function can be accessed.

• %linloop, which indicates that the lines below are going to be executed in a loop through the linguistic labels defined for the variable. Inside this loop the activation grade for each rule (or membership function) and the parameters of membership functions can be accessed.

• %end, which marks the end of the above constructs.

When defining a defuzzification method the final output value is noted as _out and a predefined array (of indefinite dimension) noted as _in may be used for intermediate values. The values of the input variables are stored in an array called _input and the number of inputs/outputs of the system is defined by _NIN and _NOUT, respectively.

Inside a %numloop the current point is noted _x and the membership function value _mx.

Inside a %linloop the activation grade is noted _a and the parameters of the membership function _p1, _p2... (where if an specific _pN is not defined its value is assumed to be 0), while _mft holds the class of the membership function: the possible values for _mft corresponds to the constants _POINTS, _DELTA, _BELL, _SIGMA, _TRIANGLE, _TRAPEZOID and _RECTANGLE.

Here are two examples of defuzzification method definition, using each of the classes of loop described above:

%Defuzzification

// Numerical methods (Loop through the universe of discourse)

CenterOfArea

%init

_in[0]=0.0;

_in[1]=0.0;

%end

%numloop

_in[0]+=_mx*_x;

_in[1]+=_mx;

%end

%exit

_out=_in[0]/_in[1];

%end

. . .

// Linguistic methods (loop through the linguistic labels)

FuzzyMean

%requires delta bell triangle

%init

_in[0]=0.0;

_in[1]=0.0;

%end

%linloop

_in[0]+=_a;

if (_mft==_TRIANGLE) _in[1]+=_a*_p2;

else _in[1]+=_a*_p1;

%end

%exit

_out=_in[1]/_in[0];

%end

. . .

%%