WO1997013210A1

WO1997013210A1 - Method and system for dynamically modelling and visualizing data

Info

Publication number: WO1997013210A1
Application number: PCT/CA1996/000666
Authority: WO
Inventors: Edward Sitarski; Kezheng Gan
Original assignee: Numetrix Limited
Priority date: 1995-10-04
Filing date: 1996-10-04
Publication date: 1997-04-10
Also published as: AU7119696A

Abstract

A computer implemented system for dynamically modelling and visualizing data accessible to a plurality of users comprising a data store and a plurality of workstations for accessing data sets in said data store. The workstations allow accessed data sets to be manipulated and/or displayed and send manipulated data sets back to the data store for storage therein. An interface acts between said data store and the plurality of workstations. The interface registers with the workstation, accessing data from the data store and, determining when the two or more workstations access a common data set. The interface updates the common data set at other workstations automatically when one of the workstations manipulates the common data set.

Description

METHOD AND SYSTEM FOR DYNAMICALLY MODELLING AND

VISUALIZING DATA

TECHNICAL FIELD

The present invention relates to a data model visualization system. More specifically, the present invention relates to a method and system for dynamically modelling and visualizing data to allow a user to dynamically manipulate and visualize data models from a common data pool via a graphical user interface.

BACKGROUND ART

Distributed Resources Planning, (DRP) is a methodology for perfoiming distribution and inventory planning which has become well known in industry over the past decade. Similarly, Material Resources Planning, (MRP) is a methodology, again well known in manufacturing industries, for facilitating material planning. All DRP and MRP systems are software- database-computer based systems which share several common characteristics namely, they all use a data model and perform basic net requirement (inventory projections) and replenishment calculations. The calculated net requirements are used to fulfil a warehouse's requirements for customer demand and safety stock which in turn becomes the demand which drives scheduling and manufacturing utilization at the manufacturing plants. In order to build the data model required to calculate the net requirements, the data model must be able to model factors such as manufacturing, shipments, inventory levels and customer demand ie. , the distribution chain.

However, there are numerous factors or constraints that most

DRP systems are not designed to consider. For example, manufacturing plants have limited production capacity, warehouses have limited floor space, shipping and receiving services have a limited hourly flow through and shipping fleets have a finite capacity. Further to this end, all of these constraints have an associated cost which must be considered when searching for the best solution to a given situation. Consequently, if the DRP system, does not take the above factors or constraints into consideration, the data model will not accurately reflect the actual environment and therefore any calculations made using the data model will be inaccurate.

Yet another disadvantage of conventional DRP systems is that they are batch oriented systems which do not provide for real-time analysis or manipulation of the data model. Batch oriented systems update information at regular predefined time intervals. Typically, these time intervals, are in terms of hours rather than minutes or seconds. Consequently, it is often very difficult to make accurate business decisions the data supporting the decision is often not up-to-date.

In large organizations having various facilities spread across a country, dynamic, real-time updating of business data in the DRP system becomes an important factor especially when considering the frequency with which the data is changing. Furthermore, due to the batch type operating environment, a single user employing the system is not in contact with changing data generated by other users on the system for often lengthy time intervals (between batch updates).

As a further complication, by the very nature of organizations, data relating to different aspects of the organizations business are stored in different formats and locations. Often it is required to use data stored in one format and/or location with a program which may be at another location and/or which may require data in a different format. While a knowledgable programmer may be able to create powerful scripts and/or programs to perform the access and translation of data, usually only on an as-needed basis, problems exist with this technique in that a less knowledgable (or non-programming) user cannot easily accomplish such a task. Furthermore, it is unrealistic to expect planners and managers who typically require access to the data, to possess such skills.

Therefore in light of the above-identified presently available systems and the numerous disadvantages associated with such systems, there is a need to provide a method and system for dynamically modelling and visualizing data.

DISCLOSURE OF THE INVENTION It is an object of the present invention to provide a novel method and system for dynamically modelling and visualizing data.

According to one aspect of the present invention, there is provided a computer implemented system for dynamically modelling and visualizing data accessible to a plurality of users comprising: a data store; a plurality of user stations for accessing data sets in said data store, said user stations allowing accessed data sets to be manipulated and/or displayed and sending manipulated data sets back to said data store for storage therein; and an interface acting between said data store and the plurality of user stations, and registering with said user station, the interface determining when said user stations access common data sets, said interface updating said common data sets automatically when one of said user stations manipulates the common data set.

According to another aspect of the present invention there is provided a computer implemented process for dynamically modelling and visualizing data accessible to a plurality of users comprising the steps of: establishing a data store; enabling a plurality of workstations for accessing data sets in said data store, said workstations allowing accessed data sets to be manipulated and/or displayed and sending manipulated data sets back to said data store for storage therein; and creating an interface acting between said data store and the plurality of workstations, said interface registering with said workstation accessing data from said data store and, determining when said two or more workstations access a common data set, said interface updating said common data set at other workstations automatically when one of said workstations manipulates the common data set.

BRIEF DESCRIPTION OF THE DRAWINGS

A presently preferred embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a dynamic modelling and visualization system in accordance with an embodiment of the present invention;

Figure 2 shows an architecture of an MVC network component of the system of Figure 1 ;

Figure 3 shows a typical MVC session of the system of Figure 1 ;

Figure 4 shows a main window graphical user interface of a user desktop component of Figure 1 ;

Figure 5 shows a list of available views associated with an open selection made with respect to Figure 5;

Figure 6 shows a portion of a process to create a single view associated with a create selection made with respect to Figure 5;

Figure 7 shows a view customization window associated with a single option selected in the window of Figure 6; Figure 8 shows a units window associated with the view customization window of Figure 7;

Figure 9 shows a display field associated with the view customization window of Figure 7;

Figure 10 shows a compound view window associated with a selection made in Figure 5;

Figure 11 shows a typical view display of a VT and/or a template chart associated with a user defined application model; and,

Figure 12 shows a typical view of a VT data editor associated with the user defined application model.

BEST MODE FOR CARRYING OUT THE INVENTION

Referring to Figure 1, a method and system for dynamically modelling and visualizing data in accordance with the present invention is indicated generally at 20.

The system 20 is designed to allow users at a plurality of workstations to access data sets stored in a shared data pool via an interface. When a user accesses a data set from the datapool, the user may manipulate a view and/or share the data set depending on the configuration of the workstation. Multiple workstations may access the same data set. If one workstation manipulates the data in the data set, the changes in the data are automatically conveyed to the interface which updates the data in the data pool as well as the data in the same data sets accessed by other workstations. This allows common data accessed by multiple users to be updated in substantially real-time if one of the users modifies the data set. Specifics of the system 20 will now be more clearly described.

As shown in the Figure, system 20 is partitioned into a multi-user level 24 and a single user level 28 representing one of the workstations.

At multi-user level 24, there is provided a plurality of common data repositories 32, each containing a base set of data 36 which has been translated by a translator 40 from a plurality of independent data repositories 44. For example, in many large business environments such as a manufacturing operation, it is common to have data which relates to different aspects of the manufacturing operation stored in different formats and locations. Independent data repositories 44 for example, may include a production planning data repository at a manufacturing location, a finished goods inventory data repository at a warehouse location and a demand forecasting data repository at a head office location. The plurality of data repositories 44 may further differ from each other in that the data stored therein may be in different formats including, but not particularly limited to, RDBMS (Relational Database Management Systems), ASCII files (either fixed length of token delimited), ODBC (Open Database Connectivity) or OODBMS ( Object Oriented Database Management Systems). The method and system by which translator 40 translates data repositories 44 into a base set of data 36 stored in data repositories 32 will not be discussed further but is as disclosed in United States Patent Application 08/222,296, the contents of which are incorporated herein by reference.

The base set of data 36 stored in the data repositories are configured as tables. Within each table are a plurality of tuples representing the actual data. The base set of data 36 stored in the data repositories 32 are placed into one or more desired formats and allow for a realistic model, representative of the business of the organization, to be created. The model for example may include customer orders, forecasts, inventory plan, production plan, products etc.

The base set of data 36 is linked to one or more model objects 48 via a model server 52. Model objects 48 represent a data set from base set of data 36 that is defined by a triplet. The triplet consists of a connection name, a table name, and a selection predicate expression. Each component of the triplet respectively identifies the data repository 32 from which the name of the table from data repository 32 and the tuples from the table, all of which define model object's 48 data set. Multiple model objects 48 may access the same tuple set provided that each individual model object 48 uses different parts of the table. The definition model objects 48 is known each time system 20 is initialized however, the physical tuples are read on a demand basis only.

Model objects 48 do not have any visual attributes associated with them. Model server 52 is also responsible for maintaining internal cache consistency between model objects 48. When initialized, model server 52 internally caches a physical tuple set of the data as requested by the model object 48 triplet. Consequently, model objects 48 may share this physical tuple set and it is the responsibility of model server 52 to synchronize updates of the tuple set between model servers. Additional model objects 48 may be defined by a user from a Graphical User Interface (GUI) 49 connected to model server 52. The GUI 49 also has the capability of changing the selection predicate expression thereby changing the tuples called from the table. It is also contemplated that it is further possible to have multiple model servers 52 each with their respective model objects 48 share the same tuple set and hence the same data. In this case a synchronization mechanism would have to ensure integrity of data changes and updates.

In summary, multi-user level 24 acquires data from independent data repositories 44, translates the data into one or more desired formats, to form a base set of data 36. The base set of data 34 represents an accurate picture of the business of the organization. Model server 52 links one or more model objects 48 which directly access data stored in base data set 36, to a user workstation 28.

Workstation 28, generally comprises a model-view-controller (MVC) network 56 and a desktop 68. MVC network 56 is defined by one or more visualization tools (VTs) 60 and/or one or more manipulation tools (MTs) 64. VTs 60 and MTs 64 are predefined visualization and manipulation objects respectively, which the user selects in order to perform a specific operation on one or more underlying model objects 48. A list and brief description of VTs 60 and MTs 64 currently included in system 20 can be found at Appendix A. The desktop 68 allows a user to select from a plurality of templates 66. Templates 66 represent a predefined set of VTs 60 and MTs 64 connections which perform commonly required operations to one or more object models 48 and when selected, establishes these connections to create an MVC network. A summary of the templates presently available to system 20, and examples of data fields included in the template can be found at Appendix B. Desktop 68 also allows the user to select a VT 60 to append to an MVC network 56 created through selection of a template 66. However, MTs 64 are transparent to the user. This is due to the fact that MTs 64 are low level tools employed by the templates 66.

Desktop 68 provides a graphical user interface (GUI) which allows the user to build an application model 72 by selecting the desired model object 48 and linking any one of a number of predefined VTs 60 and MTs 64 by selecting template 66 and possibly one or more additional VTs 60. When the user defined MVC network is launched, application model 72 is constructed. In other words, passing object model data 48 through MVC network 56 results in the manipulation of data through the user defined VTs 60 and MTs 64 connections which builds application model 72 for display to the user.

As shown in Figure 2, the underlying architecture of the MVC network 56 is further illustrated. As mentioned previously MVC network 56 is defined by a connection of components 88 such as model objects 48, VTs 60 and MTs 64 and which is linked to one or more model objects 48. Each object has assigned to it at least one role which is determined by the nature of the object. The roles that are available are models 76, views 80 and controllers 84. If the component 88 is assigned the model 76 role that object is used to store and manage data. If the component 88 is assigned a view 80 role that object is used to display data only ie., the data cannot be changed. If the component 88 is assigned a controller 84 role, that component 88 is used to add/delete and/or change data. Further to this end, the component 88 is able to assume more than one role. For example, component 88 could assume the roles of a combined view 80/controller 84 which has the ability to display data and add/delete and/or change data. Component 88 could also assume the combined roles of a model 76/view 80/controller 84 which is able to manage, display and add/delete and/or change data.

A message protocol ensures that all components 88 are instructed automatically when any data changes, so that real-time data consistency can be achieved. MVC network protocol is defined as follows:

i) Model 76 can accept data add/delete/change messages from controllers 84, which it is allowed to accept or refuse, ii) Model 76 is responsible to inform all views 80 connected to it when it accepts a change.

iii) View 80 is responsible to accurately reflect all update messages which are received from model 76.

As a more specific example, consider a data editor which, in the present system 20, is one of the available VTs 60. The data editor has the capability of viewing and changing data and therefore assumes the role of a combined view 80/controller 84. Figure 3 illustrates a typical MVC session. In the present example, VT 60 or in this case, the data editor, is connected to at least one object model 48. This connection is invoked by a user via desktop 68 which results in the formation of application model 72. Application model 72 will be described in further detail below. When establishing the connection between object model 48 and VT 60, VT 60 first sends a register message 92 to model object 48. Model object 48 then responds by sending a Send Data Definition Message 96 back to VT 60 followed by a Send All Data to View 100. Register message 92 is in the form of a triplet which identifies the object name, execution model name in which the component 88 is operating and the role of the component 88 ie, model 76, view 80, view 80/controller 84 etc. Send Data definition message 96 informs, component 88 the data characteristics of the model object 48. In this manner, the MVC protocol is self-describing in that model objects and VTs 60 register with each other prior to establishing a connection.

As further illustrated in Figure 3, other messages such as Change, Add and Delete message passed from VT 60 are responded to with corresponding verification update messages. A partial list of these messages can be found in Appendix C. It is also possible for any component 88 to establish registration with any other component 88. For example a model object 48 can register with a second model object 48.

The above-described MVC network protocol and messaging the MVC architecture provides for dynamic data updates. For example, if three VTs 60 are attached to a single model object 48, a change made through one of the VT 60 would be reflected automatically in remaining two VTs 60. This event can occur when several users operating different application models 72 on separate workstations link to the same model object 48. These changes are effected by the user at the application model 72 level.

Figure 4 illustrates a main window 100 of desktop 68. The user may select from a plurality of menu items which includes a File item 104, Windows Item 108, Desktop item 112, Views item 116, Alerts item 120, Network item 124, Horizon item 128, and Help item 132. File item 104 gives the user access to system 20 via login option which permits the user to register with system 20. File item 104 also provides an exit from system 20 via an Exit option. Window item 108 permits the user to select a view from a list of predefined views 110 configured by a user in prior sessions.

Desktop item 112 provides access to options such as Load, Save, Save As and Options, of which none of these are shown. From Desktop item 112 the user can load predefined desktop configurations, save the current version or change the current settings. Desktop item 112 also provides the user with the flexibility of selecting default options via the Options item. Such options could include, an Automatic start-up when the user logs in, Alert views on start-up, open with a default view on start-up, or default units of measure.

Selecting Views item 116, as shown in Figure 4, displays a drop down menu which includes such options as Open 136, Create 140, Copy 144, Customize 148 and Delete 150. As shown in Figure 5, upon selecting Open option 136, the user is presented with a window 154 which identifies a list of views which are available to the user. Upon selecting Create option 140, as shown in Figure 4, a cascading menu presents two additional options, namely, Single 155 or Compound 156 allowing the user to select between creating a single view or a compound view.

The process of generating a single view is shown in Figure 6. Upon selection of Single option 155, window 158 appears which permits and the user to select template 66 from a list of available templates and a VT 60 from a drop down menu. Once selected, a view customization window 162 appears, as shown in Figure 7, permits the user to select various customization options. These option include, but are not limited to items such as Filtering Criteria 166, default Units 170, Display Fields 174. Selecting Units 170 and Display Fields 174 produces windows 178 and 182, shown in Figures 8 and 9 respectively. Display Fields 174 permits the user to edit the display fields which are generated by the view template. Selecting units 170 permits the user to select the desired measurement units with which the data will be presented. For example, if the user is working with an inventory model, the available units could include cases, pallets, six packs or twelve packs.

As shown in Figure 10, if the user specifies a compound view by selecting Compound 156, a window 186 presents the user with a list of available single previously defined views 190. Two or more of views 190 may be compounded to generate the desired results. For example, a user may wish to chart manufacturing utilization against warehouse utilization for comparison of performance.

Once the user has completed the view customization window 162 in the case of a single view or window 186 when a compound view is selected, the settings are saved when exiting from the respective windows. Application model 72 is launched by selecting View Open option 136 where the view, whether newly created or simply selected from the existing views, is displayed.

When an application model 72 is launched, the underlying MVC network 56 constituted by linked VTs 60 and MTs 64 as defined by the selected template 66 and possibly a selected VT, registers with the selected model object 48 and if permitted, establishes a connection. Model object 48 reads the tuple data into the intemal cache of model server 52 as requested by the template and tools. The tuple data is passed up through MVC network 56 where VTs 60, and MTs 64 constituting the MVC network 56 manipulate and filter the data as per its configuration as determined by the user. Two examples of a typical application model 72 are shown in Figures 11 and 12. In some instances, the user has the ability to edit data in application model 72 if the visualization tool selected assumes the role of a View/Controller, as shown in Figure 12. For example, if VT Table is selected (see Appendix A) as the desired visualization tool VT 60 when application model 72 was created, the user is capable of editing data as desired. When the user changes or updates data in application model 72, the change to data is passed through MVC network 56 to model object 48. As previously mentioned, each model object 48 is aware of all MVC networks registered to it via the MVC protocol. Consequently any changes to data made via MVC network 56 by a user is, if accepted by model object 48, instantly updated to all views via other MVC networks 56 registered to the model object. In effect, this means that a plurality of users sharing the same object model at the same time, instantly see the effects of each user operating with that particular model object. Figure 11 shows application model 72 as a view 80 in which the view is in the form of a chart.

Another feature available to system 20, via desktop 68, is Alert item 120 shown in Figure 4. Alerts are tools which monitor data passing through MVC network 56 to detect certain conditions which the user defines via Alert item 120. For example, a user operating a view which displays information regarding raw materials inventory could instruct the view to trigger an alert condition when a particular raw material quantity falls below a certain level. If and when this event occurs, the data in violation of the alarm condition is displayed to the user in tabular form with a user defined message describing the alarm condition. As previously mentioned, the alert feature may be set as a default feature which activates automatically when the user logs-in to desktop 68. In this case, when desktop 68 opens, a Violation Table is displayed which informs the user of any alert conditions present in the default application model 72. Altematively, the user may also view the Violation Table at any time by selecting an "Inspect" option in a pull down menu once Alert item 120 has been selected.

Yet another feature available to system 20 is a hyper-link control which allows the user to view other attributes associated with a particular piece of data. The hyper-link feature (not shown) is a direct user control which may, for example, be activated by double-clicking on a conventional mouse button. Operation of the hyper-link feature can be illustrated by the present example. The user opens the violation table and sees that a particular inventory level has fallen below the predefined alert value. In order to facilitate a solution to the problem, the user may wish to see an inventory status view to get a better idea of what the inventory situation is like for a given category of items. By double-clicking on the data item in the violation table, the hyper-link feature launches the inventory status view which is becomes the current application model 72 displayed on desktop 68. The user may further hyper-link on any field in the inventory status, for example, a customer order field to open a new view associated with the particular data item.

It is further contemplated that additional features may be included in system 20. For example a versioning feature could be included which allows users to save a copy of the data associated with a particular application model 72. This feature would be particularly useful if the user wished to perform "what-if scenarios on application model 72. In this situation, the dynamic features of system 20 would not be required as the user requires manipulating the model at will to generate various situations. The version of application model 72 would be saved separately allowing to manipulate data with having the changes reflected in substantially real time to other users on the system.

The present invention has been described with reference to a presently preferred embodiment. Other variations and embodiments of the present invention may be apparent to those of ordinary skill in the art. Accordingly, the scope of protection sought for the present invention is only limited as set out in the attached claims.

APPENDIX A

VT Table - A dynamic data editor allows user to edit application model.

Model VT Table (M) (VC)

Crosstabing,

Expressions,

Inverse Expressions,

Aggregations,

Highlighting,

Hide/Show Fields

VT List - This tool is employed to browser a list and contains data editing features.

Model VT List (M) (VC)

Sort Order, Sort Position, Display Order

VT Chart - Permits user to display object model 48 in chan form.

Model VT Chart (M) (V)

Sorting, Data Colors, Data Position

V - view VC - View controller H rlVC - Model View C Controller VT Form Manages a set of records. Permits user to edit one or more records at a time.

Model VT Form (M) (VC)

On-Screen

Field Positions

MT Selection Manages messages to MVC components 88. Attaches to an object model 48.

MT Aggregate - Dynamically maintains the aggregation of tuple data. Supports aggregation functions such as Sum, Average, Min and Max.

MT Join - Dynamically adds reference fields to tuple data.

MT Cross tab Permits user to alter the key structure of object model 48 data. GUI interface to permit editing.

Component (V)

Model MT Crosstab Component ( ) (MVC) (VC)

- Crosstab Field \ Organization \

Component (VC)

MT Calculate - Permits the user to perform calculations on model object 48 data.

MT Model Link Permits two models to be linked together.

Model 1 MT Crosstab Model2 (M) (VC, VC) (M)

APPENDIX B Templates

1. Inventory Status

1.1 Display Fields:

• Starung Inventory

• Scheduled Producuon

• Enroute

• On-order

• Untransmitted (Deployment orders that have not yet been made into trucks)

• Deployment Orders

• Customer Orders

• Forecast

■ Minimum Inventory

• Safety Stock

• Build Inventory

• Maximum Inventory

<Nott: Th* following Display Fields ara calcutsttd from othtr fMds>

• Effective Demand - This is the effective demand based on selected forecast consumption rule.

• Ending Inventory - This is tbe projected inventory ignoring Deployment Orders and is calculated as follows: (Ending Inventory - Starting Inventory + Scheduled Production + Enroute ♦ Untransmitted + On-order • Effective Demand).

• Ending InventoryfDeployment) • This is the projected inventory including Deployment Orders and is calculated as follows: (Ending Inventory - Starting Inventory + Scheduled Production + Enroute + Untransmitted + On-order + Deployment orders - Effective Demand).

• Days of Coverage - This is the number of days of cover that the Ending Inventory or the Ending Inventory Deployment) (depending on what is used in the view) represents based on Effective Demand.

• Weeks of Coverage - This is tbe numoer of weeks of cover that the Ending Inventory or the Ending Iπventory Deploymeru) (depending on what is used in tbe view) represents based on Effective Demand.

• Inventory Carrying Cost - By period Inventory Carrying Cost

2. Storage Utilization

2.1 Display Fields:

• Ending Inventory - Total inventory at location (may be projected)

• Minimum Capacity

• Standard Capacity

• Premium Capacity

<NOTE: The following Display Fields are calculated from other fields>

• Projected Capacity Utilized - This is Ending Inventory convened into the same units as capacity

• Capacity Utilization - (= Projected Capacity Utilized / Standard Capacity)

• Standard Storage Costs - By period Standard Manufacturing Costs

• Premium Storage Costs - By period Premium Manufacturing Costs

•' Total Storage Costs - (= Standard Storage Costs + Premium Storage Costs)

3. Material Handling Utilization

3.1 Display Fields:

Total Item Inbound

Total Item Outbound Total Throughput Capacity Minimum Inbound Capacity Standard Inbound Capacity Premium Inbound Capacity Minimum Outbound Capacity Standard Outbound Capacity Premium Outbound Capacity

<NOTE: The following Display Fields are calculated from other flelds>

Projected Inbound Capacity Utilized - This is the Total Product Inbound converted into the same units as capacity

Projected Outbound Capacity Utilized - This is the Total Product Outbound convened into the same units as capacity

Inbound Capacity Utilization - (= Projected Inbound Capacity Utilized / Standard Inbound Capacity)

Inbound Standard Material Handling Costs - By period Inbound Standard Material Handling Costs

Inbound Premium Material Handling Costs - By period Inbound Premium Material Handling Cost • Total Inbound Mateπal Handling Costs - (= Inbound Standard Mateπal Handling Costs + Premium Inbound Mateπal Handling Costs)

• Outbound Capacity Utilization - (= Projected Outbound Capacity Uuhzed / Standard Outbound Capacity)

• Outbound Standard Mateπal Handling Costs - By penod Outbound Standard Material Handling Costs

• Outbound Premium Mateπal Handling Costs - By period Outbound Premium Material Handling Cost

• Total Outbound Material Handling Costs - (= Outbound Standard Material Handling Costs + Premium Outbound Matenal Handling Costs)

• Total Material Handling Costs - (= Total Inbound Material Handling Costs + Total Outbound Material Handling Costs)

4. Manufacturing Utilization

4.1 Display Fields:

• Scheduled Production

• Minimum Capacity

• Standard Capacity

• Premium Capacity

<NOTE: The following Display Fields are calculated from other fields>

• Projected Capacity Utilized - (= Scheduled Production(in units) / Manufacturing Rate) , may need time conversion depending on whether Manufactuπng Rate & Capacity are same time units.)

• Capacity Utilization - (= Projected Capacity Utilized / Standard Capacity)

• Standard Manufacturing Costs - By period Standard Manufacturing Costs

• Premium Manufacturing Costs - By period Premium Manufacturing Costs

• Total Manufacturing Costs - (= Standard Manufacturing Costs + Premium Manufacturing Costs)

5. Transportation Utilization

5.1 Display Fields: Ongin Code

Ongin Descπpuon

DesunaUon Code

Destinauon Descπpuon

Mode Type Code

Scheduled Shipments

Mimmum Capacity

Standard Capaαty

Premium Capaαty

<NOTE: The following Display Fields are calculated from other fields>

Projected Capacity Utilized - This is the Scheduled Shipments convened into the same units as capaαty

Capaαty Uulizauon - (= Projerted Capaαty Uulized / Standard Capacity)

Standard Transportauon Costs - By peπod Standard Transportauon Costs

Premium Transportauon Costs • By penod Premium Transportauon Costs

Total Transportauon Costs • (= Standard Transportauon Costs + Premium Transportauon Costs)

. Customer Orders

.1 Display Fields: Order Number

Customer Code

Customer Name

Customer Locauon

Demand Prionty code

Due Date

Item Code

Item Descπpuon

Quanuty

Status Code 7. Net Requirements

7.1 Display Fields:

• Net Requirements

• Minimum Capacity

• Standard Capacity

• Premium Capacity

<NOTE: The following Display Fields are calculated from other fields

• Projected Capacity Uulized - (- Net Requιrements(ιn umts) / Manufactunng Rate) , may need ume conversion depending on whether Manufactunng Rate & Capacity are same ume umts.

• Capacity Uulizauon - (= Projerted Capaαty Utilized / Standard Capaαty)

• Standard Manufacturing Costs • By penod Standard Manufactunng Costs

• Premium Manufactunng Costs - By period Premium Manufacturing Costs

• Total Manufactunng Costs • (= Standard Manufactunng Costs + Premium Manufactunng Costs)

8. Enroutes

8.1 Display Fields: Origin Code

Origin Descripuon

Destination Code

Destination Descπpuon

Ship Date

Arrival Date

Original Due Date

Item Code

Item Descripuon

Quanuty

Carrier

Mode

Bill of Lading

-25-

SUfcSTITUTE SHEET (RULE 26) 9. On-Order

9.1 Display Fields: Ongin Code

Ongin Descπpuon

DesUnaUon Code

DesUnauon Descπpuon

Due Date

Item Code

Item Descπpuon

Quanuty by Item

Total Quanuty of Shipment

Bill of Lading

10. Deployment Orders

10.1 Display Fields: Origin Code

Origin Descπpuon

DesUna on Code

DesUnauon Descπpuon

Due Date

Item Code

Item Descnpuon

Quanuty

11. Demand Priorities

11.1 Display Fields:

• Demand Component

• Demand Priority Code

• Demand Prioπty Descπpuon

APPENDIX C Messages

The following table is a brief summary of some of the messages used by MVC:

Model Messages:

Model Message Description

Receive Add Message from Controller Sent by a Controller when something is to be added Receive Delete Message from Controller Sent by a Controller when something is to be deleted Receive Change Message from Controller Sent by a Controller when something is to changed Send Add Message to all Views Sent by a Model to all its Views when an Add is accepted Send Delete Message to all Views Sent by a Model to all its Views when a Delete is accepted

Send Change Message to all Views Sent by a Model to all its Views when a Change is accepted

Send All Data To View Sent by a panicuiar View when requested by a Controller

View Messages:

View Message Description

Receive Add Message from Model Sent by the View's Model when something is added Receive Delete Message from Model Sent by the View's Model when something is deleted Receive Change Message from Model Send by the View's Model when something is changed Delete All Data Message from Model Send by the View's Model when everything is to be deleted

Controller Messages:

Controller Message Description

Send Add Message to Model Sent when the Controller wants to add something to its Model Send Delete Message to Model Sent when the Controller wants to delete something from its Model Send Change Message to Model Sent when the Controller wants to change something in its Model

Send Delete All in View Message Sent when the Controller wants delete everything in a particular to Model View

Send Add All in View Message to Sent when the Controller wants add everything in a panicuiar View Model

Claims

What is claimed is:

1. A computer implemented system for dynamically modelling and visualizing data accessible to a plurality of users comprising: a data store; a plurality of workstations for accessing data sets in said data store, said workstations allowing accessed data sets to be manipulated and/or displayed and sending manipulated data sets back to said data store for storage therein; and an interface acting between said data store and the plurality of workstations, said interface registering with said workstation accessing data from said data store and, determining when said two or more workstations access a common data set, said interface updating said common data set at other workstations automatically when one of said workstations manipulates the common data set.

2. A computer implemented method for dynamically modelling and visualizing data accessible to a plurality of users comprising the steps of: establishing a data store; enabling a plurality of workstations for accessing data sets in said data store, said workstations allowing accessed data sets to be manipulated and/or displayed and sending manipulated data sets back to said data store for storage therein; and creating an interface acting between said data store and the plurality of workstations, said interface registering with said workstation accessing data from said data store and, deteirnining when said two or more workstations access a common data set, said interface updating said common data set at other workstations automatically when one of said workstations manipulates the common data set.