[ Main page | About Your System | About Fuzzy Logic | The Importance of Explainability | Commercialising ]

About Your System

I have built a simulation of gas-delivery logistics, showing how this can be controlled by an expert system. As explained on the main page, this is not yet a commercial product but an MVP — Minimum Viable Prototype. However, it demonstrates the principles, and could be scaled up to a commercial product. I have ensured that it needs no specialist knowledge to understand, so it should be easy for the government inspectors to understand and for you to explain to them. For further information about fuzzy logic and how the expert system works, please see About Fuzzy Logic . I explain these at a non-technical level on the current page.

To access the system, please go to https://expertsystemdemos.net/sim_gas.html . Do this on a laptop or desktop computer rather than a phone, as the simulation needs ample screen space for pictures and diagnostics.

The Simulation

Key elements visible in the simulation are a warehouse, a house, a road, and a stock of gas bottles. These reduce the complexities of gas-supply to their simplest: one company delivering gas to one householder, whose stocks and situation they monitor, replenishing via lorry deliveries when necessary. By influencing gas consumption, the weather, symbolised by sky colour and by the sun, snow and clouds top right, also plays a rôle. A typical session is shown below:

As mentioned above, you should use a desktop or laptop computer. Start up a web browser: I generally use Firefox. Visit the simulation page, https://expertsystemdemos.net/sim_gas.html . You will see some green buttons, an empty text area thereunder, a picture, and an empty "Logistics Rules" panel on its right.

If this is the first time you have run it on this browser in this session, the sky in the picture will be black. If it is blue or grey instead, refresh the page. You may have junk left over from a previous run, which will probably stop things working.

You should now see a black sky. Press `Initiate`. The sky will turn blue or grey, and a weather symbol and some gas bottles will appear. You will also see some programmery-looking text above the picture, some logistics rules on the right, and three short ticker-tape–style graphs plus some figures in the top-left of the picture.

Now press `Next`. The graphs will extend themselves; the figures near them will update; the gas bottles will change; and a new set of logistics rules will scroll into place.

Wait for any action on the screen to stop, then press `Next` again. Do this a few times, watching the picture and the rules.

You could now try an automatic run. Restore the simulation to its resting state by reloading the page. Then press `Initiate`. Then press `Auto-Run`. Wait until at least 12 steps have elapsed, so that you see one complete seasonal cycle. Then press `Stop Auto-Run`.

Next, press `Show Gas-Company Letter`. A welcome letter from the gas company will pop-up, detailing their delivery policy and how this depends on the weather. This will show you how gas stocks are measured, how consumption is affected by weather, and how deliveries are affected by weather.

Finally, scroll back through the logistics rules and consider how they make sense given events in the simulation.

Units

The most important thing is that a gas bottle holds 40 pounds of gas, which I am advised is realistic. In text and in graphics, gas levels are expressed either in numbers of bottles or in pounds. The gas-company letter referred to above uses these units in its explanations.

Time is explained in the following section. Here, the basic unit is a week. Deliveries are scheduled in terms of weeks, and graphs' X axes are marked off in weeks.

Time

Just as films and books use narrative compression to squash down a sequence of events to essentials, so does the simulation. There are two seasons, summer and winter. Each lasts for six weeks, with the winter weather being worse than the summer, and demanding more gas for heating. In screen time, a week passes quickly, in round about five seconds. However, gas usage, as illustrated by the gas-company letter, is meant to be realistic.

The significant timepoints in a week are these:

1. The week begins. The data structure representing the week gets pre-filled with its _1 fields for gas level, contents of bottles, and other characteristics. These are visible in the text above the picture. On the picture, the step number and calendar update.
2. The simulator generates the week's weather and updates the sky colour and weather symbols. To add some unpredictability to the simulation, the weather symbols are only approximations. The actual weather may be better or worse, and is indicated by a number on a scale of 1 to 10. In the text panel above the picture, this is visible as an entry such as "weather": [ "summer_sun", 8.91 ] . High numbers are good weather; low are bad.
3. The bottles under the house update to reflect the week's initial gas level. The gas-level graph adds a new point for it, at the start of its week.
4. About a second of screen time later, the bottles under the house deplenish to reflect depletion due to weather. The week has now almost finished.
5. The logistics manager deals with deliveries in the initial logistics queue for the week, shown in the field logistics_queue_1 . He or she does this by searching the queue for entries whose step number is the current step — think of it as a date — and removing them from the queue. If there were any, the manager sends them out: you'll see a lorry drive from the warehouse to the house and back. The gas bottles under the house then replenish and the gas-delivery graph updates.
6. That happens late on the week's notional Sunday. Too late to affect much else, random events such as a bear attack may then happen. If so, and the gas level is affected, the bottles under the house will update again.
7. Very close indeed to the end of the week, the logistics manager plans new deliveries and adds each one to the logistics queue. The earliest they can happen is next week, but they may well happen later, especially when demand is low. The calculation of delivery amounts and times is done by our fuzzy-logic rules, a trace through which will be seen in the diagnostics panel. When added to the queue and seen in the text panel, each delivery looks like [ [ "deliver", 1 ], 4 ] where the first number is an amount of bottles and the second is a step number. Here, this is being used in the same way we'd use a date, as a tag indicating when to do something.
8. The week ends. The data structure representing the week gets augmented with its _2 fields for gas level, bottles, and logistics queue. These are visible in the text above the picture, and will become the _1 fields for the following week.

This is obviously a very simplified model, which I've adopted for ease and speed of implementation. A more realistic simulation could be built, and might indeed be useful as a teaching aid. Even without the graphics, the internals of such a simulation will be needed as an adversarial environment against which to test your product. However, the current system is easy to explain, and should impress the inspectors by the effort made to produce clean graphics that clearly depict how the rules interact with their environment.

Graphs

There are three graphs to the right of the step number and calendar. These represent gas consumption, gas level, and gas deliveries respectively. Icons for a flame, a gas bottle, and a lorry are beside them as reminders.

The gas-consumption graph gets updated right at the end of the week, as can be seen by comparing its activity with the other two graphs. It records total consumption for the week: that due to weather plus that due to other events. There is one point per week, drawn midway through the week's stripe.

The gas-level graph gets updated just after the start of the week, once the weather and initial gas-bottle stocks have been depicted. There is one point per week, drawn at the beginning of the week's stripe.

The gas-deliveries graph gets updated on the notional Sunday, at the end of the week. There is one point per week, representing the aggregate of all the week's delivery amounts. Unlike with the other graphs, the plotter does not connect points with lines, drawing instead a vertical line down to the X axis.

In all three graphs, a stripe is 100 pounds high. Remember that a bottle holds 40 pounds, so this is a bit less than two bottles. Entries do sometimes rise above 100, but the scaling has worked pretty well for most test runs. A higher maximum value would make fluctuations in the gas level less obvious, while having different scales for different graphs would make them harder to compare.

The Rules

Note that there are two sets of rules: one about whether to override normal policy, and one about delivery timing. Note also that every rule has a condition such as weather is summer_good and a conclusion such as days_to_delivery is four_weekly.

Each condition gets tagged with a coloured number, which is repeated in brackets at the end of the rule.

The number measures how much the condition holds. It's like saying that I, at 6 foot 4 inches, am tall, whereas Eddie at 5 foot 10 inches, is only a bit tall. Or that my shoes, which are 11 in UK sizes, are large, whereas Eddie's, at 7, are average. There is no precise definition of "tall" or "large", and no cut-off point such that 6 foot 4 inches (say) is tall but 6 foot 3 inches is not. Similarly with weather. But we can say, a bit vaguely, that something is 10% tall or 70% big or 90% chilly, and that is what we are doing here. Behind the scenes, a rule-evaluator is handling all this, using fuzzy logic to ensure that these numbers get used in a consistent and mathematically respectable way.

Basically, this is a way of having lots of rules that forecast different aspects of a problem, working out how well each one fits the data, and then integrating all their advice, paying most attention to the rules that fit best. Technically speaking, this is Mamdani fuzzy logic, and is a well-understood part of artificial intelligence, covered in all textbooks. The underlying maths has been around since the 1960s, when it was invented by Lotfi Zadeh. Web searches for topics such as "fuzzy-logic controllers" will find many examples of real- world use: a favourite one is fuzzy control of fans and washing-machines. For more information, see About Fuzzy Logic , especially the shoe-size system demo.

The Knowledge Base

In expert-systems terminology, a knowledge base is the collection of rules and other infrastructure that contains the expert knowledge being consulted. Our knowledge base is shown below, and contains the rules seen above plus their fuzzy sets. Most of the set membership functions are triangular, with one or two ascending and descending. If you remember that the numbers in the tri, up and down structures are positions on the relevant measurement scale — weather severity, delivery delay, customer stock loss, or priority — then their meaning should be clear. Consult the page on fuzzy logic for more info.

As noted in the last section, there are two lots of rules. The priority rules run first. If they decide on an immediate override, then the second lot will either not run, or will run but be ignored. Instead, the logistics manager will queue a request for immediate delivery. Otherwise, the delivery schedule calculated by the second lot of rules will be used.

if weather be summer_good then 
   days_to_delivery := four_weekly.

if weather be summer_poor then 
   days_to_delivery := three_weekly. 

if weather be winter_ok then 
   days_to_delivery := two_weekly. 

if weather be winter_chill then 
   days_to_delivery := weekly. 

if customer_spoilage be spoilage_small then
  priority := follow_standard_procedure.
  
if customer_spoilage be spoilage_big then
  priority := override.
  
low( weather, 1 ).
high( weather, 10 ).
scale( weather, '1-10' ).
fuzzy_set( weather, winter_chill, tri( 1, 2.5, 5 ) ).
fuzzy_set( weather, winter_ok   , tri( 3, 4.5, 6 ) ).
fuzzy_set( weather, summer_poor , tri( 5, 6.5, 8 ) ).
fuzzy_set( weather, summer_good , tri( 7, 8.5, 10 ) ).
% Step sets by 2.

low( days_to_delivery, 0 ).
high( days_to_delivery, 35 ).
scale( days_to_delivery, 'Days' ).
fuzzy_set( days_to_delivery, immediate   , tri( 0, 1, 3 ) ).
fuzzy_set( days_to_delivery, weekly      , tri( 2.5, 7, 11.5 ) ).
fuzzy_set( days_to_delivery, two_weekly  , tri( 9.5, 14, 18.5 ) ).
fuzzy_set( days_to_delivery, three_weekly, tri( 16.5, 21, 25.5 ) ).
fuzzy_set( days_to_delivery, four_weekly , tri( 23.5, 28, 32.5 ) ).
% Step sets by 7, sides 4.5.

low( customer_spoilage, 0 ).
high( customer_spoilage, 400 ).
scale( customer_spoilage, 'Pounds' ).
fuzzy_set( customer_spoilage, spoilage_small , tri( 0, 2.5, 6 ) ).
fuzzy_set( customer_spoilage, spoilage_medium, tri( 4, 15, 20 ) ).
fuzzy_set( customer_spoilage, spoilage_big   , up( 15, 30, 400 ) ).

low( priority, 1 ).
high( priority, 10 ).
scale( priority, '1-10' ).
fuzzy_set( priority, follow_standard_procedure, down( 1, 6 ) ).
fuzzy_set( priority, override                 , up( 4, 10 ) ).

This is obviously simplified compared with real life. I chose a set of rules that was easy for you to explain, maintained stable stock levels over long periods, and was small enough that you could see the entire ruleset in a trace — i.e. in the logistics panel. Nevertheless, they demonstrate the principle, and could be scaled up to a full product.

Results

Running the simulation a number of times will show that the rules maintain stability for quite a long time, without the customer's stocks either crashing to zero or overrunning the available storage space. You can see this in the screenshot shown earlier. It demonstrates, in a simple way, what your final product is to achieve for your customers.