Tuesday, October 13, 2015
Tuesday, October 14, 2014
Fuzzy Logic Introduction


Fuzzy logic starts with and builds on a set of user-supplied human language rules. The fuzzy systems convert these rules to their mathematical equivalents. This simplifies the job of the system designer and the computer, and results in much more accurate representations of the way systems behave in the real world.Additional benefits of fuzzy logic include its simplicity and its flexibility. Fuzzy logic can handle problems with imprecise and incomplete data, and it can model nonlinear functions of arbitrary complexity. "If you don't have a good plant model, or if the system is changing, then fuzzy will produce a better solution than conventional control techniques," says Bob Varley, a Senior Systems Engineer at Harris Corp., an aerospace company in Palm Bay, Florida.
You can create a fuzzy system to match any set of input-output data. The Fuzzy Logic Toolbox makes this particularly easy by supplying adaptive techniques such as adaptive neuro-fuzzy inference systems (ANFIS) and fuzzy subtractive clustering.
Fuzzy logic models, called fuzzy inference systems, consist of a number of conditional "if-then" rules. For the designer who understands the system, these rules are easy to write, and as many rules as necessary can be supplied to describe the system adequately (although typically only a moderate number of rules are needed).
In fuzzy logic, unlike standard conditional logic, the truth of any statement is a matter of degree. (How cold is it? How high should we set the heat?) We are familiar with inference rules of the form p -> q (p implies q). With fuzzy logic, it's possible to say (.5* p ) -> (.5 * q). For example, for the rule if (weather is cold) then (heat is on), both variables, cold and on, map to ranges of values. Fuzzy inference systems rely on membership functions to explain to the computer how to calculate the correct value between 0 and 1. The degree to which any fuzzy statement is true is denoted by a value between 0 and 1.
Not only do the rule-based approach and flexible membership function scheme make fuzzy systems straightforward to create, but they also simplify the design of systems and ensure that you can easily update and maintain the system over time.

Fuzzy Sets

Fuzzy Set Theory was formalised by Professor Lofti Zadeh at the University of California in 1965. What Zadeh proposed is very much a paradigm shift that first gained acceptance in the Far East and its successful application has ensured its adoption around the world.A paradigm is a set of rules and regulations which defines boundaries and tells us what to do to be successful in solving problems within these boundaries. For example the use of transistors instead of vacuum tubes is a paradigm shift - likewise the development of Fuzzy Set Theory from conventional bivalent set theory is a paradigm shift.
Bivalent Set Theory can be somewhat limiting if we wish to describe a 'humanistic' problem mathematically. For example, Fig 1 below illustrates bivalent sets to characterise the temperature of a room.



The most obvious limiting feature of bivalent sets that can be seen clearly from the diagram is that they are mutually exclusive - it is not possible to have membership of more than one set ( opinion would widely vary as to whether 50 degrees Fahrenheit is 'cold' or 'cool' hence the expert knowledge we need to define our system is mathematically at odds with the humanistic world). Clearly, it is not accurate to define a transiton from a quantity such as 'warm' to 'hot' by the application of one degree Fahrenheit of heat. In the real world a smooth (unnoticeable) drift from warm to hot would occur.This natural phenomenon can be described more accurately by Fuzzy Set Theory. Fig.2 below shows how fuzzy sets quantifying the same information can describe this natural drift.

Fuzzy Set Operations

Definitions.



Universe of Discourse
The Universe of Discourse is the range of all possible values for an input to a fuzzy system.
 Fuzzy Set
A Fuzzy Set is any set that allows its members to have different grades of membership (membership function) in the interval [0,1].
 Support
The Support of a fuzzy set F is the crisp set of all points in the Universe of Discourse U such that the membership function of F is non-zero.
 Crossover point
The Crossover point of a fuzzy set is the element in U at which its membership function is 0.5.
 Fuzzy Singleton
A Fuzzy singleton is a fuzzy set whose support is a single point in U with a membership function of one.

Fuzzy Set Operations.

Union

The membership function of the Union of two fuzzy sets A and B with membership functions and  respectively is defined as the maximum of the two individual membership functions

The Union operation in Fuzzy set theory is the equivalent of the OR operation in Boolean algebra.

Complement

The membership function of the Complement of a Fuzzy set A with membership function is defined as

The following rules which are common in classical set theory also apply to Fuzzy set theory.

De Morgans law

 , 

Associativity

Commutativity

Distributivity



DESIGN GOALS

Control of the environment for large computing systems is often a far greater challenge than for rooms inhabited by people. Not only do the systems themselves generate heat, but they are often specified by their manufacturers to be maintained in as little as a plus-or-minus 1 degree (Fahrenheit) range. Humidity is also a challenge, causing, for example, corrosion and jamming of associated mechanical systems at high humidity levels and the enhanced possibility of static discharge with low levels. Humidity control is often specified to be 50% relative humidity, with a maximum swing of plus-or-minus 3% per hour.In addition, the design of a precision environmental control system also faces nonlinearities, caused by such system behavior as air flow delay and dead times, uneven airflow distribution patterns, and duct work layouts. Uncertainties in system parameters are often present, for example, room size and shape, location of heat-producing equipment, thermal mass of equipment and walls, and amount and timing of external air introduction.
Recognizing these challenges, Liebert undertook the design of a control system requiring (in general terms):

  • Precision temperature and humidity control;
  • Minimization of cycling times (i.e., the opening and closing of the damper and turning on and off of the compressor), thereby increasing reliability and component life, and also resulting in increased energy efficiency;
  • Straightforward and therefore inexpensive control electronics.
In short, Liebert wanted to precisely control with simple hardware a nonlinear system with significant uncertainties. Several traditional linear approaches were considered but proved inadequate. A fuzzy logic approach was investigated and ultimately implemented. Design specifics - The LogiCool control system has six fuzzy inputs, three fuzzy outputs, and 144 principles (rules). It runs on a Motorola 6803 microprocessor, and is programmed in C.LogiCool's fuzzy input variables are: e_temperature, the temperature relative to a setpoint; delta_T/delta_t, the rate of temperature change; e_humidity, the humidity relative to a setpoint; delta_H/delta_t, the rate of humidity change; and two proprietary variables associated with the action of the controllers.
Fuzzy outputs control: 1) amount of cooling, 2) amount of dehumidification, and 3) heat. Outputs can also be treated as fedback input variables, and time delays are treated as fuzzy outputs as well. Each fuzzy variable is assigned seven membership functions as values, with the traditional Large_Negative, Medium_Negative, Small_Negative, Near_Zero, Small_ Positive, Medium_Positive, and Large_Positive as labels. Ranges for the values of each variable are proprietary.
An example of a temperature control principle, using the as ...then ... (rather than the if ... then ...) syntax, is:
as temperature relative to set point is small_positive and temperature rate of change is medium_positive then amount of cooling is small_positive;The Liebert design also incorporates time delays into their principles. The following demonstrates both this as well as the use of a fuzzy output as a feedback variable.
as temperature relative to setpoint is small_negative and amount of cooling is small_positive then wait delay to cooling change is medium_positive;
A fuzzy OR operator (maximizer) is used as the defuzzification technique, avoiding the complicated calculations associated with a centroid approach. Liebert has found that with the large number of principles, a more elaborate approach is unnecessary. Inputs are sampled, the principle-base accessed, and outputs are updated once a second. The "long" inter-sample delay allows the 6803, a simple eight-bit microprocessor, to implement this rather large fuzzy system.

FUZZY LOGIC OBJECTIONS

It would be remarkable if a theory as far-reaching as fuzzy systems did not arouse some objections in the professional community. While there have been generic complaints about the "fuzziness" of the process of assigning values to linguistic terms, perhaps the most cogent criticisms come from Haack . A formal logician, Haack argues that there are only two areas in which fuzzy logic could possibly be demonstrated to be "needed," and then maintains that in each case it can be shown that fuzzy logic is not necessary.The first area Haack defines is that of the nature of Truth and Falsity: if it could be shown, she maintains, that these are fuzzy values and not discrete ones, then a need for fuzzy logic would have been demonstrated. The other area she identifies is that of fuzzy systems' utility: if it could be demonstrated that generalizing classic logic to encompass fuzzy logic would aid in calculations of a given sort, then again a need for fuzzy logic would exist.
In regards to the first statement, Haack argues that True and False are discrete terms. For example, "The sky is blue" is either true or false; any fuzziness to the statement arises from an imprecise definition of terms, not out of the nature of Truth. As far as fuzzy systems' utility is concerned, she maintains that no area of data manipulation is made easier through the introduction of fuzzy calculus; if anything, she says, the calculations become more complex. Therefore, she asserts, fuzzy logic is unnecessary.
Fox has responded to her objections, indicating that there are three areas in which fuzzy logic can be of benefit: as a "requisite" apparatus (to describe real-world relationships which are inherently fuzzy); as a "prescriptive" apparatus (because some data is fuzzy, and therefore requires a fuzzy calculus); and as a "descriptive" apparatus (because some inferencing systems are inherently fuzzy).
His most powerful arguments come, however, from the notion that fuzzy and classic logics need not be seen as competitive, but complementary. He argues that many of Haack's objections stem from a lack of semantic clarity, and that ultimately fuzzy statements may be translatable into phrases which classical logicians would find palatable.
Lastly, Fox argues that despite the objections of classical logicians, fuzzy logic has found its way into the world of practical applications, and has proved very successful there. He maintains, pragmatically, that this is sufficient reason for continuing to develop the field.

REFERENCES

[1] Daniel Mcneil and Paul Freiberger " Fuzzy Logic"

[2] http://www.ortech-engr.com/fuzzy/reservoir.html

[3] http://www.quadralay.com/www/Fuzzy/FAQ/FAQ00.html

[4] http://www.fll.uni.linz.ac.af/pdhome.html

[5] http://soft.amcac.ac.jp/index-e.html

[6] http://www.abo.fi/~rfuller/nfs.html

[7] L.A.Zadeh,"Making computer think like people, IEEE spectrum, 8/1984, pp 26-32 [8] S.Haack, " Do we need fuzzy logic? " Int .Jr nl .of Man-Mach.stud , vol.11, 1979, pp 437-445
Matlab Fuzzy logic



Let’s consider the following example:
We have three input criteria for computer characteristics and by them we have to determine the price of computer.
For this problem we are using Matlab program
1    1.We are typing fuzzy in command window and press Enter
2       2.In opened FIS editor we are creating 3 inputs(HDD, RAM, videocard)  and 1 output (price)

3. For 1st input we have 3 categories.  Range will be from 0 to 500.
1.mal(0 50 100 150)
2.sred(100 200 250 350)
3.bol(300 400 500 1000)

4. For second input we will have 4 categories. (Range from 0 to 16) :
1.malenkaya(0 0.5 1 1.5)
2.srednaya(1.5 3 4 6)
3.xoro6aya(5 7 10 12)
4. WOW(10 12 14 20)

5. For third input we will have 3 categories (Range from 0 to 4):
1. Bad (0 0,5 0,7 1)
2. Good (0,7 1,5 2 2,5)
3. Best (2,5 3 3,5 4)

We will have 3 categories for output:
 Then we have to build our Rules in Rules Editor. There will be 36 rules in this case.
 
Monday, October 13, 2014
Fuzzy Logic in MATLAB (Example 2)

Here we consider another example:

We need to establish the QUALITY OF TIPS in Restaurant received in result of determining FOOD and SERVICE quality.

To solve this example we use Matlab.
We type “fuzzy” in the Matlab command prompt.

Then in Edit tab we add additional input variable because we need to determine Food and Service quality. And in result we have 2 inputs: 


Then we open in Edit tab Membership Functions editor.

First input is Food quality. Let this input’s words a.k.a membership functions be:
    ·         Bad
    ·         Good
    ·         Excellent 

Second input is Service quality. Let this input’s words a.k.a membership functions be:
    ·         Weak
    ·         Average
    ·         Perfect

Our output variable is going to be Tips quality. Let this output’s words a.k.a membership functions be:
    ·         Poor
    ·         Ordinary
    ·         Great


In every input and output we put suitable for us Range and Params in which lays every membership function.

Then we have to open again in Edit tab Rule editor and build following rules due to our conception of received Tips. 


Then in View tab we choose Surface viewer which represents graphical result of our rules and membership functions.



Fuzzy Logic in  MATLAB (Example 1)

We consider following example:

We have SCORES in Figure Skating based on Technique and Performance. In output we have to determine the Result due to the scores.
For solving this task we use “Matlab”.
In Command Window we type “fuzzy” and press enter. In opened FIS Editor we create 2 inputs by pressing Edit tab and adding additional variable input.

We need two inputs and one output. In example we use Technique and Performance as Inputs and Result as Output.

In our next step we determine our Membership Functions for each input and output by pressing Membership Function in Edit tab.

For Technique input we use next MF:
  •       Weak
  •       Good
  •       Excellent
For Performance input we use following MF:
       ·     Dirty
       ·     Average
       ·     Clear

As our output is Result we need to determine also its MF as:
       ·         Bad
       ·         Good
       ·         Great

In every case we determine Range and Params.

Then we have to build our Rules in Rules Editor which we can open also from Edit tab.


To see resulted graphical preview of our solving we have to click View tab and press Surface.



Vendor Approaches

While the majority of our attention has been devoted to various approaches to EAI, you'll discover as you shop for solutions that each EAI vendor has its own take on what EAI is. Who's right? Who's wrong? Unfortunately, as with everything else in the EAI domain, the answer is not black and white.

EAI is a combination of problems, and each organization has its own set of integration issues to address. As a result, it is virtually impossible to find a single technological solution set that can be applied universally. A particular enterprise's EAI solution will generally require products from several different vendors. At this time, and in the foreseeable future, one-step shopping is simply not an EAI reality.

Although vendors' approaches to EAI vary considerably, it is possible to create some general categories. These include:
  • Data oriented
  • Application integration oriented
  • Process automation oriented
  • Transaction oriented
You should note that these vendor solutions are independent of the levels of EAI (database, method, application interface, and user interface), and may inhabit one, two, or three of the levels of EAI.

Data-Oriented

Vendors that promote the data-oriented approach to EAI make the case that integration should occur between the databases—that is, databases should be viewed as the primary points of integration; thus they believe in data-level EAI. Even within data-level EAI, there are many approaches, and each vendor is quick to promote its particular solution. Data-level solutions can be categorized into two categories: data replication and data federation.

Data Replication

Data replication means moving data between two or more databases, databases that can come from the same vendor or many vendors, or even databases that employ different models. The trick with database replication is to account for the differences between database models and database schemas by providing the infrastructure to exchange data. Such solutions are plentiful and inexpensive. Most relational database vendors, including Sybase and Oracle, provide database replication services within their own product offering. These replication engines typically exist within the database engines, at either end (see Figure 20.3).

Figure 20.3 Database replication solutions are offered by most major database vendors.

Many database-oriented middleware solutions are on the market that provide database replication services as well. This is accomplished by placing a layer of software between two or more databases. On one side, the data is extracted from the source database or databases, and on the other side, the data is placed in the target database or databases. Many of these solutions provide transformation services as well—the ability to adjust the schemas and the content so they make sense to the target database (see Figure 20.4).

Figure 20.4 Database-oriented middleware solutions provide database replication solutions as well.

The primary advantages of database replication are simplicity and low cost. Database replication is easy to implement, and the technology is cheap to purchase and install. Unfortunately, data replication loses value if methods need to be bound to the data or if methods are shared along with the data. To accomplish these things, method sharing solutions such as transaction-oriented or application integration–oriented EAI must be considered (see the discussion of these solutions later in this chapter).

Data Federation

Although database federation has been around for awhile, the solution set has been perfected only recently. Database federation is the integration of multiple databases and database models into a single, unified view of the databases (see Figure 20.5). Put another way, database federations are virtual enterprise databases that are comprised of many real physical databases.

Figure 20.5 Data federation software is middleware that allows an application to view a number of databases through a single view.

Database federation software places a layer of software (middleware) between the physical distributed databases and the applications that will be viewing the data. This layer connects to the back-end databases using available interfaces and maps the physical databases to a virtual database model that exists only in the software. The application uses this virtual database to access the required information, and the database federation handles the collection and distribution of the data as needed to the physical databases.
The advantage of using database federation software is the ability to bind many different data types into one unified enterprise-wide model.
Database federation allows access to any connected database in the enterprise through a single well-defined interface. This nails the data-level EAI problem, providing the most elegant solution. While this solution, unlike replication, does not require changes to the source or target applications, changes do have to be made at the application level to support federated database software. This is due to the fact that different interfaces are being used to access a different database model (the virtual database).

Application Integration–Oriented

Application integration–oriented product solutions focus on the integration of both packaged and custom applications by using well-defined application interfaces, and supports the data, method, application interface, and user interface EAI levels. Right now, the interest in integrating popular ERP applications (e.g., SAP, PeopleSoft, and Baan) has made this the most exciting EAI sector. (While distributed object and transaction-oriented solutions may be applied to this space—because here you program your way to success—message brokers vendors are promoting their products as the preferred solution.)
Message brokers support application integration–oriented solutions by connecting into as many custom or packaged applications as possible through adapters. They also connect into technology solutions that include middleware and screen scrapers as points of integration (see Figure 20.6).

Figure 20.6 Application integration–oriented solutions link to packaged or custom applications or other points of integration to integrate applications.

The advantage of using application integration–oriented products is the efficient integration of many different types of applications. In just a matter days, it is possible to connect a SAP R/3 application to a Baan application, with the application integration–oriented solution accounting for the differences between schema, content, and application semantics by translating on the fly the information moving between the systems. Moreover, this type of solution can be used as a database replication solution, which is also able to connect to application interfaces.
The downside to using application interface–oriented products is that there is little regard for business logic and methods that may exist within the source or target systems, logic and methods that may be relevant to a particular integration effort. In such a case, transaction- or distributed object–oriented solutions (composite applications or a pure method-level approach) are probably a better choice. Ultimately, application interface–oriented technology will learn to share methods as well as information, perhaps by joining forces with transaction-oriented or distributed object–oriented solutions. However, for now you will have to make an either/or decision.

Process Automation–Oriented

Process automation–oriented products, as covered in the previous chapter, are those solutions that layer a set of easily defined and centrally managed processes, or workflow solutions, on top of an existing set of processes contained within a set of enterprise applications (see Figure 20.7).

Figure 20.7 Process automation–oriented products layer a set of centrally managed processes on top of an existing set of enterprise processes.

The focus is to bring together any relevant enterprise processes to obtain the maximum amount of value while supporting the flow of information and logic between these processes. These products view the middleware or the plumbing as a commodity and provide easy-to-use visual interfaces for binding these processes together.
In reality, process automation is another layer of value on top of existing EAI solutions, solutions that include message brokers, application servers, distributed objects, and other middleware layers. They offer a mechanism to bind disparate processes together and to create workflow solutions that automate tasks once performed manually. However, by diminishing the importance of the plumbing, they miss the larger picture. In reality, no single EAI vendor has solved the plumbing issues. Ultimately, the solution to these issues will be delivered by a combination of process automation and middleware vendors. That being the case, it is clear that the binding of middleware and process automation tools represents the future of EAI.

Transaction-Oriented

Transaction-oriented products are those middleware products that use the notion of a transaction, with connectors to back-end systems, to integrate applications, a clear method-level EAI approach. Examples of these products include TP monitors and application services. Although transaction-oriented products can be used for data integration, method-level integration is where these products shine. With these products, it is possible to create common methods (transactions, really) and share those methods among many connected applications.
The advantages of transaction-oriented products are scalability and reliability. However, success with these products requires a tremendous amount of coding. As time marches on, transaction-oriented middleware will combine forces with messaging and message brokers, providing EAI architects and developers with the best of method-level, data-level, and application interface–level EAI.