Directed by a digital twin, real-time data from the ecosystem or projection data from simulations are processed. As an outcome, analysis and explanation of all actions and captured data is available from each performance.
An example from the OtterServer is presented in the book, The OWL and the Architect, describing the performance of operating three pizza stores. Here is an extract from the book describing the pizza store simulation:
Putting It All Together
The pizza store simulation demonstrates a transaction-based operation using executable ontologies. The demo uses the Resource Event Agent (REA) academic disciple ontology to create a knowledge-based system for multiple pizza stores that use multiple providers of supplies.
The REA approach to tracking business operations is perfectly suited to pizza stores. Each store sells pizzas to customers in exchange for payment, following the concept of “exchange” described in REA. To complete orders for pizzas, a store must convert raw materials to produce the pizza, following the concept of “convert” described in REA. The store’s purchase of raw ingredients from suppliers further applies the concept of “exchange”.
The pattern applied in the simulation is presented in Pavel Hruby’s book on model-driven design using REA (Pavel Hruby, Model-Driven Design using Business Patterns, Springer, 1998). The models – and even the code needed – to provide the exchange between a pizza store and a customer is included in the book. Many other examples of patterns are also presented in the book, including patterns describing the “convert” pattern of REA.
The simulation does not attempt to cover all of the operations needed to run a pizza store. The purpose of the simulation is to demonstrate the functions of the framework, rather than to show how to run an actual food franchise.
The book presents the ontologies for REA and those of the PizzaStores ontology. It also describes the contracts, the stores, the suppliers, the pizzas, and the ingredients. These are the named objects stored in the Abox database. It also shows snapshots of the execution of the simulation.
Rather than snapshots, the following are videos of an execution of the simulation.
Simulation Page
The simulation page shown below provides three options: Initialize Data, Run Simulation, and Start SCA Heartbeat. The SCA Heartbeat option is not described here.

The left side of the page shows the performance of the three stores. It displays every transaction as sales data and shows a bar chart that summarizes the accumulated results of expenses and revenues.
The right side of the page shows the performance of three providers (the suppliers of the pizza ingredients). It displays every transaction for restocking a store’s supplies. It summarizes the accumulated results of sales by store in a bar chart.
All numeric values shown are in round dollars, although in the simulation, the values carry fractions. Also the page, as shown in the video, clips most of the transactions from view.
Initialize Simulation
The video that follows shows the initialization of the data. During this process, all the data needed to run the simulation is added to the Abox database. This includes stores, suppliers, customers, pizzas, pizza ingredients, and contracts.

When finished, the response displayed indicates that the initialization is complete.
Simulation
The simulation video below begins by showing which day is being simulated at the top of the page.
Each day begins with each store replenishing their supplies based upon an economic order quantity. On the first day, all the stores need all of the supplies.
Pizza orders are randomly generated for store, pizza type, and quantity. Therefore, every run of the simulation is unique. It’s like a race to see which store will sell the most pizzas.

Completion Analysis
Once complete, the video below shows how placing the cursor over store expense values will display the cost of the ingredients consumed. Placing the cursor over revenue shows the sales of the pizza types sold. Placing the cursor over provider values shows the ingredients provided to each store.

Continuing the Simulation
Although the first five days in the previous videos are shown as being complete, the simulation can be run again in five day increments, with each beginning with the store supplies recorded in the Abox database.
The following video picks up with the next five days:

Summary
These videos show a digital twin. There are three store-actors dialoguing with customer-actors and dialoguing with three supplier-actors. In exchange for money, customer-actors request pizzas from store-actors. Store-actors then satisfy the orders by converting ingredients into pizzas. The store-actor restocks supplies from the supplier-actors by exchanging money to receive the ingredients needed to make the pizzas.
All transactions are processed and recorded according to REA.