The World's Source For Fuzzy Logic Solutions
This page contains a brief description of the 15 built-in objects that are provided with TILShell.
| Chart | Connect | Debug | Emit | External |
| Member | Model | Package | Procunit | Project |
| Rule | Rulebase | Simulate | User | Var |
Chart objects are used to define charts for viewing data during debugging. Debug objects contain Chart objects, which contain no other objects. Chart objects are completely defined by their options.
Multiple Chart objects may be defined in a single Debug object.
Connect objects are used to define the input and output variables (Var objects) of processing objects (Externals, Packages, Procunits, Rulebases, and Users). Connect objects do not contain any other objects and are contained in Project and Package objects.
A connect object has a FROM field and a TO field. A connect object sends information FROM the object that supplies it TO the object that consumes it.
Multiple Connect objects may be defined within a Project or Package object.
The Editor for the Connect object is the Graphical Project Editor.
The Debug object stores information about the debugging setup of TILShell. This includes variables transmitted from the target to the host during online debugging, Others, watch variables, trigger conditions and Chart objects.
Only one Debug object is allowed per Project.
Emit objects are used to embed text or source code in the output code when an FPL source file is compiled. Emit objects are not processing objects, so they cannot be connected to Project object.
External objects are used to embed an external reference and call to a user defined function implemented in the target environment's language. They are processing objects and may be connected to Var objects.
For support within TILShell, you may optionally supply a DLL with a function that implements the External object so it can be executed during simulation.
Multiple External objects may be defined in a Project object.
Member objects are used to define membership functions for variables (Var objects). They are only allowed within Var objects and cannot have any objects defined within them. Members can be defined in one of three ways. A member can be defined as an equation, as a piece-wise linear function, or as one of three pre-defined functions. Members are used in rules to compute premise and conclusion values for Var objects. However, if a Var object is a signed long or unsigned long, it cannot have membership functions. A member object is evaluated whenever a call to a rule which uses the member is called.
The Editor for the Member object is the Variable and Membership Function Editor.
Model objects define the model that runs during simulation. The model is defined in the FPL Script Language in two sections, the init section and the body section.
Multiple Model objects may be defined in each Simulation object.
The Editor for the Model object is the Split Window Editor.
Package objects contain the objects necessary to define a fuzzy knowledge base. They are used to define subsidiary knowledge bases in the top level Project object or in another Package object. Packages are often used in complex FPL files to create a hierarchical structure within the FPL file.
Packages can have Rulebase, External, Var, Connect, Procunit, User and other Package objects as child objects. A package is executed whenever its parent object is called or when it is called directly.
Multiple Package objects can be defined within a project or package object.
The Editor for the Package object is the Graphical Project Editor.
Procunit objects are used to perform non-fuzzy processing on variables using the FPL Script Language. Like Model objects, they consist of two sections, the Body and Init sections. Procunit objects are supported by the TILShell simulation facility, and by the Fuzzy-C Compiler.
Multiple Procunit objects may be defined within a Project or Package object.
The Editor for the Procunit object is the Split Window Editor.
The top level object of an FPL file is the Project object. There can only be one project object per file. The name of the project is the name the user uses to call the fuzzy system from his driver program. When a project is called, the project and all of its associated subobjects are executed. A project can contain Connect, Debug, Emit, External, Package, Procunit, Rulebase, Simulate, User, and Var objects.
The Editor for the Project object is the Graphical Project Editor.
Rule objects are used to define the production rules of a fuzzy knowledge base. Rule objects may only be defined in Rulebase objects and cannot have any objects defined within them. Each rule is a single IF-THEN rule with the IF part consisting of one or more antecedents (which combine to form a single premise) separated by an operator (AND, OR, user defined operator) and a THEN part consisting of a list of one or more conclusions.
An antecedent is a comparison of a Var value and a membership function or Boolean expression and a conclusion is an assignment statement assigning an output variable a value. The value assigned to an output variable varies with the type of inference and defuzzification methods defined by the user.
Multiple Rule objects may be defined within a Rulebase object.
The Editors for the Rule object are the Rulebase Editors.
A Rulebase object defines a fuzzy rulebase. It is this rulebase which changes the values of the output variables of the knowledge base. A rulebase typically contains a list of IF-THEN Rule objects which act to define the desired fuzzy rulebase. Its inputs and outputs are defined using Connect objects.
During execution, all of the rules in a rulebase are called with their combined results forming the output of the object. A Rulebase object is executed whenever a call to its parent object is called or when it is called directly.
Multiple Rulebase objects may be defined within a Project or Package object.
The Editors for the Rulebase object are the Rulebase Editors.
Simulate objects contain all the options and objects needed to support simulation in TILShell. Several Model objects can be defined in a single Simulate object. For example, one model could be defined to use a simple Euler's method of integration, and another method could be defined to use an RK4 method.
If more than one Model object is defined in a Simulate object, you must choose which Model object you want to use when you start a simulation.
FPL provides the capability for users to define new classes of objects. In this way, FPL becomes user extensible. User defined objects are processing objects that can be connected to Var objects. User defined objects have no child objects.
Some example uses of user defined objects are: calling sophisticated numerical routines such as digital filters or neural networks to process variables in the fuzzy system, communication links between TILShell and any I/O or data acquisition boards connected to the host PC, and reading data from a special file format to provide inputs or outputs to your fuzzy system.
The user extends FPL to include new object classes by listing the user defined object class names in an external file called FPL.INI and supplying optional routines that implement those object classes. The user may then utilize the new object class by creating instances of it in TILShell with the Project Manager or the Graphical Project Editor.
A Var object corresponds to the concept of a variable in a conventional programming language with the exception that vars have more information in them than simply the value for the variable. Member objects are contained in Var objects, which in turn are contained by Project or Package objects.
Multiple Var objects may be defined within a Project or Package object.
The Editor for the Var object is the Variable
and Membership Function Editor.
This site is http://www.ortech-engr.com/fuzzy/objects.html.
Send inquiries, comments, or suggestions to webmaster@ortech-engr.com.
| Page Stats: Visitors -- Last Modified on: -- Thanks for visiting from: . |
![[Togai Name]](fzy_images/TogaiName.gif){kind=small}