Scalable Knowledge Interchange Broker: Design and Implementation for Semiconductor Supply Chain Systems
by
James Melkon Smith
A Thesis Presented in Partial Fulfillment of the Requirements for the Degree
Master of Science
Approved November 2012 by the Graduate Supervisory Committee:
Hessam Sarjoughian, Chair Hasan Davulcu Georgios Fainekos
ARIZONA STATE UNIVERSITY December 2012
ABSTRACT
A semiconductor supply chain modeling and simulation platform using Linear Program (LP) optimization and parallel Discrete Event System Specification (DEVS) process models has been developed in a joint effort by ASU and Intel Corporation. A Knowledge Interchange Broker (KIBDEVS/LP) was developed to
broker information synchronously between the DEVS and LP models. Recently a single-echelon heuristic Inventory Strategy Module (ISM) was added to correct for forecast bias in customer demand data using different smoothing techniques. The optimization model could then use information provided by the forecast model to make better decisions for the process model. The composition of ISM with LP and DEVS models resulted in the first realization of what is now called the Optimization Simulation Forecast (OSF) platform. It could handle a single echelon supply chain system consisting of single hubs and single products
In this thesis, this single-echelon simulation platform is extended to handle multiple echelons with multiple inventory elements handling multiple products. The main aspect for the multi-echelon OSF platform was to extend the KIBDEVS/LP such
that ISM interactions with the LP and DEVS models could also be supported. To achieve this, a new, scalable XML schema for the KIB has been developed. The XML schema has also resulted in strengthening the KIB execution engine design. A sequential scheme controls the executions of the DEVS-Suite simulator, CPLEX optimizer, and ISM engine. To use the ISM for multiple echelons, it is extended to compute forecast customer demands and safety stocks over multiple hubs and products.
Basic examples for semiconductor manufacturing spanning single and two echelon supply chain systems have been developed and analyzed. Experiments using perfect data were conducted to show the correctness of the OSF platform design and implementation. Simple, but realistic experiments have also been conducted. They highlight the kinds of supply chain dynamics that can be evaluated using discrete event process simulation, linear programming optimization, and heuristics forecasting models.
ACKNOWLEDGEMENTS
I would like to acknowledge Dr. Hessam Sarjoughian for his mentorship throughout my work at ASU and for being the advisory for this research. From Intel, I would like to give special thanks to Dr. Gary Godding for his past work and ongoing help within the domain of supply chain. Also from Intel, I want to give thanks to Dr. Asima Mishra and David Bayba for help with the definition of the Inventory Strategy Module and Multi-Echelon Inventory Optimization. For implementing the first iteration of the Inventory Strategy Module within a Discrete Event System
Specification (DEVS) model and going through the verification process of the code, I want to give thanks to Dr. Mohammed Muqsith, a former student of ASU. Thank you to the members of the supervisory committee for qualifying this work. Finally, thanks to Intel for continuing to sponsor this project.
TABLE OF CONTENTS Page LIST OF TABLES ... ix LIST OF FIGURES ... x CHAPTER 1 INTRODUCTION ... 1 1.1 Purpose Statement ... 1 1.2 Intended Audience ... 1 1.3 Problem Definition ... 1
1.3.1 Semiconductor Supply Chain ... 1
1.3.2 Optimization, Simulation, and Forecast ... 2
1.3.3 Knowledge Interchange Broker ... 4
1.3.3.1 XML Schema Design ... 4
1.3.3.2 KIB Structure ... 5
1.4 Contributions ... 7
2 BACKGROUND AND RELATED WORKS ... 10
2.1 Background ... 10
2.1.1 Definition of Supply Chain ... 10
2.1.2 Multi-Echelon Inventory Optimization & Sequential Based Stock ... 12
2.1.3 XML and XML Schemas ... 12
CHAPTER Page
2.1.4.1 History ... 13
2.1.4.2 Overview of Transformations ... 15
2.1.5 Integrating Forecast Model with Optimization and Simulation Models ... 18
2.2 Related Works ... 22
2.2.1 Using Model Predictive Control in a Supply Chain ... 22
2.2.2 Inner and Outer Loop Optimization ... 22
3 APPROACH ... 24
3.1 Knowledge Interchange Broker Model XML Schema ... 24
3.1.1 Premise for Design ... 24
3.1.2 Decomposition of XML ... 26
3.1.3 Generalization ... 27
3.1.4 Removal of String Parsing ... 29
3.2 Using the KIB with the Inventory Strategy Module ... 32
3.3 Development of KIB ... 33
3.4 Experimentation/Evaluation ... 34
4 CONCEPT & XML DESIGN OF KIB ... 36
4.1 File Decomposition ... 36
4.2 Module Schema ... 37
CHAPTER Page
4.2.2 Module Element ... 38
4.2.3 DataInput and DataOutput Elements ... 39
4.2.4 DataVariable Element ... 39 4.3 Control Schema ... 40 4.3.1 Control Element ... 40 4.3.2 Execution Element ... 41 4.4 Relationship Schema ... 42 4.4.1 Relationship Element ... 42 4.4.2 Map Element ... 42
4.4.3 Source DataOutput Element ... 43
4.4.4 Target DataInput Element ... 44
4.4.5 Transformation Element ... 44
4.4.6 Source DataVariable Element ... 47
4.4.7 Target DataVariable Element ... 48
4.4.8 Index Element ... 48
4.4.9 Field Element ... 48
5 SCHEMA IMPLEMENTATION ... 49
5.1 Object Structure and Data Structure Mapping ... 49
CHAPTER Page
5.1.2 KIB Module Objects ... 50
5.1.3 KIB Control Object ... 52
5.1.4 KIB Relationship Objects ... 53
5.1.5 Adding an Interface ... 54
5.1.6 Designing a KIB Model ... 56
5.2 ISM Implementation ... 57
5.3 Single Echelon Implementation ... 64
5.3.1 Single Echelon Timeline ... 64
5.3.2 Configuration and GUI ... 67
5.3.3 KIB Implementation ... 73 5.4 Multi-Echelon Implementation ... 79 5.4.1 KIB Implementation ... 79 6 RESULTS ... 81 6.1 Regression Testing ... 81 6.2 Evaluation of Scalability ... 81 6.3 Experiments ... 82 6.3.1 Single-Echelon Results... 82
6.3.1.1 Execution Time Analysis ... 82
CHAPTER Page
6.3.1.3 Simulation Weekly Step/Optimization Weekly Step ... 84
6.3.1.4 Simulation Daily Step/Optimization Weekly Step ... 86
6.3.2 Multi-Echelon Results ... 89
6.3.2.1 Computation of Upper Echelon Safety Stock ... 89
6.3.2.2 Simulation Weekly Step/Optimization Weekly Step ... 90
7 CONCLUSIONS ... 94
7.1 Future Work ... 95
REFERENCES ... 97
APPENDIX A: ABBREVIATIONS AND DEFINITIONS ... 99
LIST OF TABLES
Table Page
1. Array to Set Lines Transformation Example ... 17
2. Historic and Forecasted Data Example ... 21
3. XML File Content Breakdown ... 82
LIST OF FIGURES
Figure Page
1. Supply Chain Model Composition Structure ... 4
2. High Level View of KIB Interaction Model for DEVS and LP ... 4
3. Original Conceptual Design of Model to Model Transformation ... 7
4. Inventory Model ... 11
5. Shipping Model ... 11
6. Customer Model ... 11
7. Supply Chain Example ... 12
8. Types of Data Aggregation (Godding 2008) ... 16
9. Disaggregation Example ... 18
10. Hub H1, Product P4 – Historic Data ... 19
11. Hub H1, Product P4 – Forecast Data over Time ... 20
12. Graph of Table 2 ... 21
13. KIB Model Interaction ... 24
14. KIB Mapping ... 25
15. Proposed Conceptual Design of Model to Model Transformation ... 26
16. Original KIB XML Definition Example ... 27
17. Module Input/Output String Definition Example ... 30
18. Data Transformation String Definition Example 1 ... 31
19. Data Transformation String Definition Example 2 ... 31
20. Data Transformation String Definition Example 3 ... 32
21. Control Type String Definition ... 32
Figure Page
23. Interface Relationship with KIB ... 34
24. KIB_Paths.xsd Schema Graphic Representation ... 36
25. KIB_Modules.xsd Schema Graphic Representation Level 1 ... 37
26. KIB_Modules.xsd Schema Graphic Representation Level 2 ... 38
27. KIB_Control.xsd Schema Graphical Representation ... 40
28. KIB_Relationship.xsd Schema Graphic Representation Level 1 ... 42
29. KIB_Relationship.xsd Schema Graphic Representation Level 2 ... 43
30. KIB_Relationship.xsd Schema Graphic Representation Level 3 ... 44
31. KIB_Relationship.xsd Schema Graphic Representation Level 4 ... 47
32. UML KIB Entry Point Objects ... 49
33. UML Objects Relating to KIB_Modules.xsd Part 1 ... 51
34. UML Objects Relating to KIB_Modules.xsd Part 2 ... 52
35. UML Object Relating to KIB_Control.xsd ... 53
36. UML Objects Relating to KIB_Relationship.xsd ... 54
37. InterfaceName Name Definitions ... 55
38. Instantiating DataModelNode ... 55
39. Instantiating DecisionEngineInterface ... 56
40. KIB with ISM ... 58
41. Three Model KIB Communications ... 63
42. OSF Model ... 64
43. Single Echelon Timeline ... 66
44. ISM Client Schema ... 68
Figure Page
46. System Schema ... 70
47. Single Echelon GUI: System Tab ... 70
48. Experiment Schema ... 72
49. Single Echelon GUI: Independent Experiments Tab ... 73
50. Path Definitions for KIB ... 75
51. DEVS Modules H1 KIB Definition ... 76
52. LP Modules H1 and HX KIB Definition ... 77
53. KIB Relationship Mapping for H1 ... 78
54. KIB Control Definition for Single Echelon, 7:1:1 ... 79
55. Multi-Echelon ISM Modules ... 80
56. JUnit Test Output ... 81
57. Single-Echelon Model ... 82
58. Single Echelon Execution Time ... 83
59. Using Perfect Data ... 84
60. Deterministic, 2 Week Shipping ... 85
61. Log-Normal Shipping, 2 Week Mean, 0 Week Min ... 86
62. TimeUnit Class ... 87
63. Deterministic, 14 Day Shipping ... 88
64. Log-Normal Shipping, 10 Day Mean, 8 Day Min ... 89
65. Double-Echelon Model ... 89
66. Double Echelon Result: Average Inventory at CW for Service Level ... 91
67. Double Echelon Result: Average Inventory at H1 for Service Level ... 91
1INTRODUCTION 1.1Purpose Statement
This report was written to satisfy degree requirements for Masters of Science in Computer Science and course requirements for independent study with Professor Sarjoughian in order to describe the accomplishments made in the development of the Knowledge Interface Broker (KIB). This work is also used in the development of the multi-echelon supply chain simulation project. The bottom line goal of the Supply Chain project is to develop a echelon simulation model with multi-echelon inventory strategy and optimization modules. All work must be scalable for large models on the order of hundreds of components. The purpose of model development within this system is to better understand the behavior of some semiconductor products.
1.2Intended Audience
The intended audiences for this report are the members of the graduate committee Dr. Hessam Sarjoughian [chairperson], Dr. Hasan Davulcu, and Dr. Georgios Fainekos; sponsor Intel, which includes employees working with the Supply Chain Simulation project; and anyone in the field either continuing this work or using this as a source in their own work. A portion of the code accompanying the design described in this thesis is planned to be released for general public use.
1.3Problem Definition
1.3.1Semiconductor Supply Chain
In any type of industry that needs to distribute products in different physical
locations with varying markets, there is a constant question of how much, how often, and where to distribute the products in order to meet the end demand of each
customer. Enough of each product needs to be shipped in order to meet demand as soon as products are requested to keep the customers happy and increase the chances of repeat business. On the other hand, if too much product is built, this often results in wasted inventory and financial loss to the product maker. Ideally, exactly enough product should be shipped at the right time instances to all customers in order to meet the exact demand value and nothing more.
To get a better idea of what the customers need, companies can ask for an estimate of how much product will be needed well in advance. If the customer could give perfect data, the problem could be relatively easily solved. Unfortunately, to keep customer ratings high, companies need to allow the customer to change their orders at a moment’s notice, close to the delivery date. Companies need to look at the forecasted demand numbers and compare them to the historical data to make a prediction of the customer’s actual need.
1.3.2Optimization, Simulation, and Forecast
The Optimization, Simulation, and Forecast (OSF) platform is built atop previous efforts (Godding 2008, Huang 2008). The OSF platform (Sarjoughian et al, 2012) introduces forecasting capability to earlier simulation/optimization platform built using Linear Programming (LP), Discrete Event Simulator (DEVS), and KIBDEVS/LP
(Godding 2008). The OSF is conceptualized and developed using a simple logistics supply chain which has a customer warehouse, a single shipping route, a single hub, and a single customer. The supply chain supports single products moving from customer warehouse and delivered to customer.
The optimization and simulation models are developed in
OPL-Studio is a platform managed by IBM. This platform is used to develop LP models. When an LP model is compiled by the platform, it may then run through the CPLEX optimizer to compute an optimal solution given values for the defined set of constraints. The DEVS-Suite modeling and simulation platform was built and is managed by staff and students at ASU under the guidance of Dr. Hessam
Sarjoughian. For this research, the term “model” is used to refer to an engine that can execute a set of instructions. In this sense, the DEVS-Suite simulator combined with just mentioned supply-chain process model is called the DEVS model. The KIB transforms data and control messages between the optimization and simulation models. The KIB is itself a standalone model that can be specified in XML. The KIB model in the form of XMLs has an accompanying execution engine which is
developed in Java. The KIB execution is governed using the DEVS-Suite simulator protocol. The optimization model is defined as a Linear Program (LP) and is used to compute an optimal solution given a set of constraints. It is used in this instance to determine how many products to be released from a component warehouse to a hub given the state on the model at each point. The model, built in DEVS, is a discrete-event representation of a single-echelon system which can handle a single hub shipping a single product to one customer. The executions of the DEVS, LP and KIB models are governed using the DEVS-Suite simulator protocol.
The structure of the OSF platform is shown in Figure 1. The forecast model consists of an Inventory Strategy Module (ISM) that looks at historic and forecast data to determine how much extra stock to hold at the hub. This data is sent to the optimization module for computing release command to the simulator. Even though
the execution of ISM is entirely functional, it is devised as an atomic model within DEVS in order to ensure it is used correctly alongside simulation model.
SIM => LP LP => SIM SIM (DEVS Suite) LP
KIB
ISMFigure 1. Supply Chain Model Composition Structure 1.3.3Knowledge Interchange Broker
A KIB instance is defined using XML. This XML selects the functionality of each interface and the KIB interaction model. An interface is defined as a Java class that is written to connect the functionality of any external model to the KIB model. The high level view in Figure 2 shows an example of a KIB system interfacing DEVS and LP models. DEVS Implementation Interaction Model DEVS Interface KIB Instance XML DEVS Instance LP Implementation (OPL Studio & CPLEX) LP Interface
LP Instance
Java Java
Figure 2. High Level View of KIB Interaction Model for DEVS and LP 1.3.3.1 XML Schema Design
The original KIB XML specification is difficult to be extended. Because many of the elements within the XML were labeled with the names of the interfaces themselves, if an XML schema was created, the schema would have to be re-written for each new
interface that is added to the KIB. Under each interface element defined, the schema would contain redundant definitions of nodes. This becomes cumbersome and is not scalable. The specification needs to be updated so that an XML schema can be defined to allow for XML instances using all current and future model interfaces without any change to the XML schema definition itself.
The structure of XML files created for the KIB allowed for multiple data variables for each data input or output, but these elements were defined as a single string for each data definition. This string would then have to be parsed within Java code to interpret the meaning. This same process was done upon each relationship and the control definition. This made it more difficult to define model elements, especially for someone who is not familiar with KIB semantics.
Modules within the KIB define partitions of data within the connecting models. Keep in mind that this should not be confused with the forecast modules which form the ISM, a separate model in the system. As new modules and their relationships were defined within the KIB XML, the file became large in size and difficult to manage. There was no systematic method to break up the XML definition into separate, manageable pieces. This also posed difficulties for XML reuse . If another model was created that was structurally similar, but contained different relationships and control, anew file had to be created.
1.3.3.2 KIB Structure
A module is an autonomous component within an interaction model that is given different definitions depending on the interface implementation within Java code. The design of the KIB itself called for a set of interfaces to be held within each module definition. Refer to Figure 3 for an example of a KIB instance model at the
conceptual level. When creating a KIB instance model, modules had to be conceptualized as entities that existed between two interfaces. This design was implemented due to the early formalization that each module component should have a single corresponding module component in the mapped model. As the design was expanded, the constraints needed to be relaxed in order to allow data
transformation between two modules of differing names. This can be seen in Figure 3 when DEVS in Module B needs to communicate to LP in Module C. This design added difficulty in conceptualizing the structure because now modules within the KIB not only provided links between interfaces, but links between modules of differing names were acceptable by the design too.
Module C Data Transformation LP DEVS Module B Data Transformation LP DEVS Data Transformation Module A Data Transformation LP DEVS Data Transformation Execution Control
Figure 3. Original Conceptual Design of Model to Model Transformation
The KIB also assumed that each model within the system was labeled with the same name. This not only restricts the designer to label each model with the same name, but it also makes it impossible to define multiple models within the same interface for the KIB. There was a 1:1 distinction between an interface and an
instance of a model defined in the KIB. This restricted the definition to a maximum of a single model for each interface.
1.4Contributions
The development of KIB XML schema design and refactoring of the KIB serves as a foundational component in the scalability of the OSF platform.
o The structure of the KIB has been redesigned for better usability and comprehension of model design. Since separate model designs are formed using their own definitions of module components, it makes sense to define these elements separately within the KIB.
o To define a schema that meets the current need and is scalable for future development, elements within the XML design has been generalized. The naming of elements is not used to enumerate elements within the KIB. Instead, attributes are used to select items within an enumeration.
o To better define and constrain the structure of a KIB model built in XML, post-process parsing of data has been removed. In order to accomplish this, each element of the KIB has been well defined. From these definitions, a schema was developed with the proper structure and constraints. The culmination of all this data can serve as a user’s guide for future use and development.
o This document itself serves as a user’s guide for future development of KIB models.
The ISM has been greatly expanded to test the scalability of the KIB.
o The modularization of the ISM was necessary as it is designed as a
functional formalism. Communication to and from the ISM is now handled through the KIB using a new interface.
o The ISM has been expanded to handle multiple hubs and products. Initialization of data sent through the KIB now contains arrays defining hub/product pairs.
o The design of the ISM was extended to handle multiple echelons using research on Multiple Echelon Inventory Optimization (MEIO) methods. Although, this work has yet to be completed, the structure has been put in place to send the correct sets of data through the KIB.
2 BACKGROUND AND RELATED WORKS 2.1Background
2.1.1Definition of Supply Chain
The work in this project specifically references supply chains in the semiconductor domain. A supply chain, in a very general sense, contains product generator elements followed by shipping and inventory elements with customers as end nodes. Product usually moves in one direction toward the customer, but in some circumstances, may move in a vertical or opposite direction. For simplicity, the model used in this research only allows for product to move toward the customer which, in most cases, is the path with the lowest cost and highest return.
When looking at a supply chain purely in terms of inventory movement, the supply chain consists of the model elements of inventory, shipping, and customer components which are diagrammed in figures 4, 5, and 6 respectively. The inventory model receives product from the previous element at any time. At some point, that product is moved from the incoming bucket into the store where it is processed. Product is only moved from the store to the outgoing bucket when a release command is received from the optimizer. The shipping model is similar to the inventory element with two distinctions: 1) When product is moved into the store, it is stored in buckets of higher granularity. As time progresses, product moves from one intransit bucket to the next. 2) Once the product reaches the final intransit bucket, it is immediately moved to the outgoing bucket without any release command. This means that the shipping element cannot be externally controlled once product has entered it. The customer model is simplistic in that it receives whatever product that comes to it in order to meet demand.
Outgoing Bucket Incomming Bucket Store Internal Transition Incoming Stock due to External Event Outgoing Stock due to Output Function
Inventory Model
Release due to External EventFigure 4. Inventory Model
Store Intransit buckets Outgoing Bucket Incomming Bucket Internal Transition Incoming Stock due to External Event Outgoing Stock due to Output Function
Shipping Model
Internal TransitionFigure 5. Shipping Model
Incoming Stock due to External Event
Customer Model
Demand DataFigure 6. Customer Model
Figure 7 shows an example of a simple double echelon supply chain. The “FA” inventory element on the very left represents a factory. This is where inventory is generated. The product is then shipped to the “CW" inventory element which represents the Component Warehouse. The CW may handle the packaging or another phase in assembly. Finally, the product is shipped to either the “Hub1” or “Hub2” inventory elements. Product is then immediately distributed to the “GC” elements or Geo Customer which, in the real world, is located in the same physical location as the hub.
FA
CW
Hub1
Ship
Ship
Hub2
Ship
GC1
GC2
Figure 7. Supply Chain Example
The Supply Chain Council is involved in creating a standardized framework for supply chains called the Supply Chain Operations Reference (SCOR) model. Although this research does not follow this model, the work that has been done ties in with the section of the SCOR model that pertains to “capturing the configuration of a supply chain” (“What is SCOR” n.d.). In this section, the supply chain model is broken up into segments: plan, source, make, deliver, and return.
2.1.2Multi-Echelon Inventory Optimization & Sequential Based Stock
The theory behind Multi-Echelon Inventory Optimization (MEIO) is to compute a safety stock value for each single echelon starting from the most downstream element and passing the result up. As we move up the supply chain, the average delay of each stage is applied to the customer demand. In other words, to satisfy the demand of the downstream element on time, we must release stock X weeks early where X is the time that it takes to ship product to the downstream element (Graves & Willems 2000).
2.1.3XML and XML Schemas
XML was originally developed in 1996 by the World Wide Web Consortium (W3C) for “ease of implementation and for interoperability with both SGML and HTML.” One of the goals of the XML specification is to make it easy for a developer to create documentation (“Extensible Markup Language” n.d.). This makes an XML
definition easy to read, but XML files are generally not lightweight. This data formalism was used to create KIB models because it allows someone who is less familiar with code design to develop a model.
The structure of an XML file is largely comprised of elements and attributes. Elements can contain simple or complex data. Under the classification of complex data, there may be a set of single or multiple child elements. Attributes are singleton simple data variables that can only exist within an element. The W3C organization provide a set of uses for an attribute, but in this research, all attributes defined will be used to specify a value that is attributable to an element. For further definition of XML, refer to the specifications available on the W3C website (“Extensible Markup Language” n.d.).
The structure of an XML schema was first designed in 2001 by the W3C to define the structure and constraints of an XML document (“W3C XML Schema” n.d.). Any simple value defined can be constrained to a set of values such as an enumeration of strings or a numeric value within a set range and/or granularity. For further definition of an XML schema, refer to the specifications available on the W3C website (“W3C XML Schema” n.d.).
2.1.4DEVS/LP Knowledge Interchange Broker (KIB) 2.1.4.1 History
Since 2003, Intel has been working with ASU to develop models for evaluation and improvement of its supply-chain processes. More recently, this effort has expanded to address the optimization of inventory stocking to meet or exceed specified service levels across a multiple logistics echelon. The DEVS simulator has been used to develop a skeleton model of a single-echelon supply chain. This model consisted of
inventory and shipping components. An inventory component processes stock then holds it until an appropriate release command is generated. A shipping component will hold its incoming products for a period of time before delivering them to the next component in the supply-chain process.
At every interval of time that the system runs for, an LP model is used to determine the optimal plan for the supply chain to generate release commands for the inventory components. The LP is modeled in OPL Studio which is written in C++, unlike DEVS which is developed in Java. In order to get the two models to communicate, an interface was designed to overcome not only the differences in implementation languages, but in the simulation operation as well. This interface is known as the Knowledge Interchange Broker (KIB) (Godding 2008).
The KIB at its core is conceptualized to be generic as part of Gary Wade Godding’s (2008) defense for his doctoral thesis entitled, “A Multi-Modeling Approach Using Simulation and Optimization for Supply-Chain Network Systems” (Godding 2008). It has a model that formulates data transformations under a time-based execution control scheme. Time is updated from the controlling model which is the model that also calls the KIB. For DEVS/LP, at some time interval, the LP model receives information from the DEVS (controlling) model via the KIB model. LP then computes release commands which are sent to the DEVS model via the KIB model. In this way, all communications (i.e., data transformation and control logic) between the LP and DEVS models are managed by the KIB. It is important to understand the distinction of the controlling model in the supply chain system. DEVS depends on the execution of the LP. Therefore, even though DEVS is labeled as the controlling model for the KIB, from a systematic perspective, the LP is the
model that controls the DEVS models with release commands. The purpose of Gary Godding’s thesis was to make a generic modeling system that brokers the interaction between a simulation and optimization models synchronously. The motivation behind the project was to develop a supply chain system from a modeling and simulation perspective. Different aspects within the supply chain planning process depended on differing principals and are modeled using different formalisms. The KIB concept with a basic theory is described in (Sarjoughian 2006; Sarjoughian and Plummer 2002). The concept of KIB was further developed by Gary Mayer (2009). His work can be seen in (Mayer 2009; Mayer and Sarjoughian 2009).
From the DEVS/LP KIB, different branches were created to support new methods with realizations. This includes a supply-chain system communicating between DEVS and Model Predictive Controller (MPC) as well as human and landscape dynamics with communication between DEVS and a Cellular Automata (CA) model. These realizations can be seen in (Godding 2008; Godding, Sarjoughian, and Kempf 2004; Godding, Sarjoughian, and Kempf 2007; Huang 2008; Huang et. al. 2006; Huang et. al. 2009). The work done in this thesis can be applied to any branch of the KIB as well as any possible future research.
2.1.4.2 Overview of Transformations
The way that a KIB model was defined was through an XML file where source and target modules were defined for the required interfaces as well as the necessary transformation. The XML file also provided a control which defined a controlling model element and an interval to execute. A controlling model element needed to be defined to keep track of the current time and when the interfacing models need to be executed.
As the KIB system was developed, several transformations between 3 dimensions were added. In the KIB, a set of data form a table where key values are defined. Each set may contain several single values or 1-dimensional arrays. As the KIB receives this data, it is time stamped, which forms the third dimension
(Godding 2008). Refer to Figure 8 for an example of aggregation of data from current set or sets over time. Doing the computation on the 3 dimensions of data through the KIB instead of at the source or destination models simplifies the process for the model designer. The aggregation and disaggregation of data over time
accounts for differing model granularity. Simple mathematical functions are built in such as min, max, and mean. Data may also be set to be treated as sets or units. All these features are further documented in chapter 0 with the development of the KIB XML schema.
Figure 8. Types of Data Aggregation (Godding 2008)
If the model in Figure 7 needed to be implemented into the OSF platform, this model would first need to be designed in the simulator. In this example, the simulation runs at a daily time granularity and the optimizer runs at a weekly
granularity. This means that the optimization executes once for every 7 time ticks of the simulator. At each tick of time, the inventory models report to the KIB their Beginning On Hand (BOH) and Actual Out (AO) data; the shipping models report
their in-transit data and AO data; and finally the time stamp value as a single integer value. At time of execution of the optimizer, 7 sets of data are available at the simulator data store. Only the most recent state data is meaningful to the optimizer, so only the newest set of data should be transformed.
For the optimization to read the in-transit data correctly, the array of values needs to be transformed into a row for each value. Refer to Table 1 for an example of this transformation. The array of size 2 with the value of [50, 75] is transformed so that each row contains a single integer value for quantity. This is achieved by adding the key column of period. The BOH and AO data don’t need any conditioning and can be passed right through.
Table 1. Array to Set Lines Transformation Example
Shipping
Name Product Quantity[2]
CW2HxShip P1 [50, 75]
TRANSFORMATION \/
Shipping
Name Product Period Quantity
CW2HxShip P1 0 50
CW2HxShip P1 1 75
The optimizer generates a set of release commands which needs to be distributed to each of the inventory elements. To do this, a disaggregation transformation is used. Refer to Figure 9 for an example of disaggregation. Each value is divided equally between the 7 time buckets within the simulation. The standard rounding algorithm is used to round each resulting value to the nearest integer. At each time tick, the KIB provides to the simulation a single set of values over 7 ticks. At the end of the 7th tick, the optimizer is run again for another 7 sets of
t = [0...6]
TRANSFORMATION =>
Figure 9. Disaggregation Example
2.1.5Integrating Forecast Model with Optimization and Simulation Models
The definition of the ISM was provided by personal communication with employees of Intel. This definition was then used to create a functional implementation of the model. Some arbitrary test data was also provided in order to test and qualify the functionality.
Working with Input Demand Data
The combination of hub H1 and product P4 was selected to do analysis on for this project. The chart in Figure 10 shows the comparison of Historic Forecast demand, HFC, and Actual Customer Demand, ACD, for hub H1 and product P4. This data is used to compute a bias within the ISM. All data in this chart is considered as historic data. Therefore, for example, if the current time period is week 7 then the ISM would only be able to view the data up to week 7.
Figure 10. Hub H1, Product P4 – Historic Data
At each time period, forecasts of future weeks are made. The chart in Figure 11 shows a three dimensional representation of the forecast data for the ISM. Forecasts evolve over time as new data arrives. For example, the forecast for week 11 at week 7 is 46816 units. The following week, week 8, the forecast for week 11 is 46654. Between week 7 and week 8, a total of 162 units were canceled for week 20. This volatile forecast data adds difficulty when finding an optimal solution for the system. This is, of course, what the ISM is going to bias against.
0 20000 40000 60000 80000 100000 120000 140000 160000 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 Qu an tity Week Index
Historic Data
ACD HFCFigure 11. Hub H1, Product P4 – Forecast Data over Time Computation of Safety Stock
Refer to Table 2 and the corresponding graph in Figure 12 for an example of the data the ISM uses for week 7. The data shown up to week 7 is historic data, while the data after week 7 is forecasted data. The single echelon ISM first computes a
multiplier based on the smoothing algorithm, target service level, replenishment time, and how well the historic actual customer demand did against the historic forecasted demand. Historic data is marked in blue in Table 2. The smoothing algorithm was an implementation of the smoothing interface of either exponential, kernel, or no smoothing. The target service level is a value between 0 and 100%. This this can be seen as a customer satisfaction level to be targeted. Replenishment time is the time in weeks for inventory to go from the upstream inventory, through a
shipping delay, and be available for the customer in the downstream element. This includes any time that the downstream inventory takes to process the product.
0 5 10 15 20 25 30 35 40 0 50000 100000 150000 0 5 10 15 20 25 30 35 40 Forecast Week Q u an tity Current Week
Forecast Data
100000-150000 50000-100000 0-50000Table 2. Historic and Forecasted Data Example
Week
Index Actual Customer Demand Forecasted Customer Demand 0 800 460 His tor ic Data 1 470 530 2 480 520 3 510 520 4 370 540 5 350 500 6 280 90 This Week-> 7 230 210 Next Week-> 8 190 For ec as ted Da ta 9 160 10 150 11 120 12 130 13 140 14 50 15 0
Figure 12. Graph of Table 2
A bias is calculated based on all the data that the ISM uses for the current time period. This bias is then applied to the forecasted data to produce a safety stock value. The safety stock value tells the optimizer how much extra stock on top
0 100 200 300 400 500 600 700 800 900 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Qu an tity o f Pr o d u ct Week Index ACD HFC FCCD Current Week
of the future demand to keep in inventory in order to achieve the desired service level.
2.2Related Works
2.2.1Using Model Predictive Control in a Supply Chain
The work done by Jay D. Schwartz, Manuel R. Arahal, Daniel E. Rivera, and Kirk D. Smith (2009) focuses on a supply chain planner in which the main goal is to keep inventory at a set level at a specific location using a Model Predictive Control (MPC). In this design, an MPC is connected to an inventory component in a feedback loop configuration with an injected feed-forward demand forecast signal. At each time instance, there is a set level of stock that must be left in the inventory after the inventory release of the previous instance. This set level is similar to a safety stock as discussed in 2.1.5. A fluid analogy is used to describe the process where a fluid needs to stay at a certain level within a tank. More fluid needs to be added to the tank at the same rate the fluid is released in order to maintain a given fluid level (Schwartz et al. 2009; Schwartz and Rivera 2010).
The MPC used in the configuration as described above handles the
prediction of inventory movement at each individual location. Since it does not make a prediction of the movement of product as a whole, it may not be scalable to more complex models. The LP as discussed in 2.1.4 does the same job of the MPC in this instance for simple models by setting constraints such that the expected inventory after a release will not fall below the given safety stock value.
2.2.2Inner and Outer Loop Optimization
The work done by Wenlin Wang, Daniel E. Riviera, and Hans D. Mittelmann (2009) focuses on a semiconductor supply chain system with a stochastic “outer loop,”
which runs planning at a lower granularity, and a stochastic “inner loop,” which makes day-to-day decisions at a higher granularity. Similar to what is discussed in 2.1.4, an LP optimization model is used to create planning at a lower granularity. Inventory algorithms are used to compute safety stock values, similar to the ISM discussed in 2.1.5. After the LP model is executed, the results are split over 7 days and sent to the Model Predictive Control (MPC) which makes day-to-day
optimization and planning in feedback and feedforward configurations. The MPC works similar to what is described in 2.2.1 except the data computed by the LP is also used by the MPC in order to make better predictions relating to the state of the system as a whole. (Wang, Riviera, Mittelmann 2009).
The focus of the work discussed above is on how to handle higher
granularity, stochastic demand with a plan generated by a lower granularity optimizer. This issue is outside the scope of this thesis since no day-to-day demand is provided to the system, so day-to-day demand is generated by evenly distributing the given week-to-week data into 7 buckets. Therefore, it is much easier to predict demand on a day-to-day basis by simply dividing the weekly plan generated by the LP into 7 equal buckets. However, since the work in this thesis demonstrates a design to connect model components with scalability in mind, it would be feasible to combine these works in the future.
3 APPROACH
3.1Knowledge Interchange Broker Model XML Schema 3.1.1Premise for Design
The structure of the KIB needs to be updated without changing the underlying functionality. The diagram in Figure 13 corresponds to the high level view of KIB model in Figure 2 and shows how different elements in each model are mapped to a module within the KIB. Each model implementation has a different definition as to how its module is defined. In general, a module is an atomic component of a model. During runtime, the interfaces can read from the data stored in the KIB module outputs and deposit the data into their respective models. After a model is executed, an interface can then read the output data given by its model and deposit into the correct module inputs of the KIB.
Interaction Model LP Implementation DEVS Implementation KIB Instance DEVS Interface DEVS Instance LP Interface LP Instance Atomic Model 1 Atomic Model 2 Atomic Model 3 werfasdf sdivnsknv mvomakdj Modules Atomic Models DEVS Interface Definition KIB Modules LP Interface Definitions Decision & Data Variables
DEVS Model KIB Model LP Model
Figure 13. KIB Model Interaction
Also defined within a KIB instance model is a set of mappings as depicted in Figure 14. A mapping itself defines the source module output and destination module input though which data will be routed. Within a mapping, there are a set of transformations that define how data is to be manipulated in this block.
mapping is called to execute during runtime, all transformations within that mapping will be executed based on a priority set within the KIB.
Mapping Transformation Transformation Module B Module A .. .
Figure 14. KIB Mapping
The diagram in Figure 15 shows a conceptual representation of the new XML schema design which corresponds to the same example given in Figure 3. Each model is associated with an interface within the KIB. Within each model, there are a set of modules. Unlike the previous design, modules belong to each model
(interface) and the transformations are completely separate entities from the modules. Take note that the solid arrows in the diagram show how data moves though the components during transform and not how the schema is to be defined. Since the transformation blocks are now completely separated from the modules, a source module output and target module input need to be explicitly referenced using the distinct module and data input/output names for each transformation. The control component, like the previous design, is still a separate singleton entity which references a data output line.
Si n gl eE ch el o n : D EV S Module_A Module_B Module_C LP _S E : LP Module_A Module_C Execution Control Data Trans. Data Trans. Data Trans. Data Trans. Data Trans. Module_B
Figure 15. Proposed Conceptual Design of Model to Model Transformation 3.1.2Decomposition of XML
To assess the problem with code reusability, the KIB XML can be broken up into smaller pieces. After removing the transformation entities from the modules themselves, the XML can then be broken down into three types of data. The
diagram in Figure 15 shows this split with the colors green, red, and blue. The green elements represent groupings of model definitions with their accompanying modules for the KIB. The red element in the middle then represents the module to module mapping and transformations. Finally, the blue element represents what data variable will be used as the KIB clock. The model and transformation elements can then be further decomposed by the designer as necessary.
3.1.3Generalization
Refer to Figure 16 for an example of how a KIB XML file was originally structured. The way that nodes were named did not allow a schema to be designed to satisfy current and future functionality. To correct this problem, the naming of each node can be made more general and instead use attributes and child elements to define what specific type of data there is under the element.
<?xml version="1.0" encoding="utf-8" ?> <KIBMODEL> <MODULE_SPECIFICATION Name = "H1"> <LPINTERFACE> <DataVariable Name="H_BOH"> <Type>Collection,Record,Key:String:hub,Key:String:product,Int:quantity</Type> </DataVariable> <DecisionVariable Name="H_RELEASE"> <Type>Collection,Record,Key:String:product,key:String:destination,Int:period,Float:quantity</Type> </DecisionVariable> </LPINTERFACE> <DEVSINTERFACE> <DataOutput Name="BOH"> <Type>Collection,Record,Key:String:hub,Key:String:product,Int:Quantity</Type> </DataOutput> <DataInput Name="RELEASE"> <Type>Collection,Record,Key:String:product,Key:String:destination,Int:Quantity</Type> </DataInput> </DEVSINTERFACE> <INTERFACE_RELATIONSHIP> <DEVSLPMAP> <DEVSNAME>BOH</DEVSNAME> <LPNAME>H_BOH</LPNAME> <DATA_TRANSFORMATION>NONE</DATA_TRANSFORMATION> </DEVSLPMAP> <LPDEVSMAP> <LPNAME>H_RELEASE</LPNAME> <DEVSNAME>RELEASE</DEVSNAME> <DATA_TRANSFORMATION>FloatToInteger:Round,Index:period,quantity,Quantity</DATA_TRANSFORMATION> </LPDEVSMAP> </INTERFACE_RELATIONSHIP> </MODULE_SPECIFICATION> <KIBCONTROL> <CONTROLLING_MODEL>DEVS</CONTROLLING_MODEL> <MODULENAME>Synchronization</MODULENAME> <VARIABLENAME>LP_SYNC</VARIABLENAME> <CONTROLTYPE>Periodic:DEVSCYCLES:1</CONTROLTYPE> </KIBCONTROL> </KIBMODEL> . . . . . .
The original design contained 2 interfaces; DEVS and LP. Within a KIB XML file under a module, each interface needed to be enumerated by using one of the nodes <DEVSINTERFACE> or <LPINTERFACE>. In the redefined design, a node <Interface> may be used with an attribute ‘name’ to enumerate the type of interface. To take this a step further, a model name can be attached to the interface so that there may be multiplicity of models within a KIB design. So now a node <Model> may be used with a ‘name’ attribute naming the model and an ‘interface’ attribute that connects the model to an interface. The distinct name of the model must now be referenced within the remainder of the XML.
In the previous design, in order to select which is the source interface and which is the target interface, nodes with names like <DEVSLPMAP> or
<LPDEVSMAP> were used to select a DEVS->LP or LP->DEVS mapping respectively. To make this more generic, a node <Map> may now be used with the attributes ‘source’ and ‘target’ which determine which interface is the source and which is the target. To take into account the design of the <Model> node in the generalization above and the original premise in mind, a source model, module, and data output with a target model, module, and data input must instead be defined under the <Map> element. Instead of defining source and target attributes, source and target elements may now be defined each with the attribute set model, module, and data.
The LP interface required the use of <DataVariable> and
<DecisionVariable> element for inputs and outputs while the DEVS interface used <DataInput> and <DataOutput>. This broke any sort of generalized input/output elements that could be created. Since data variables and decision variables still map
to what the LP considers as input and an output, the definitions of these elements can be changed in code to match the other interfaces to come to a more generalized definition of an input and output within the schema.
3.1.4Removal of String Parsing
Any entity of the XML that can be parsed should be further decomposed into XML attributes and elements. The following shows how each string is parsed and how the decomposition of this string can be handled by the XML file. Deeper explanations of what each of the definitions mean will be handled later on in this paper.
Module Input/Output Definition
The string in Figure 17 shows a sample definition of an input or output of a module.
o Parts ○1 and ○2 tell the KIB that the following data is a collection of record
definitions, but this is more or less ignored since all data should be a collection of records. Therefore, it will be ignored in the schema design.
o Parts ○3 , ○4 , and ○5 each define a record. If the flag “Key” is given before
the definition then the record will be a key field. This can be handled by an attribute giving a Boolean value to specify whether the field is a key or not. If the flag “Array” is given before the definition then the record will be an array. The size of the array must be given after the definition of the type or set to “Variable” if the size of the array is a variable size. This can be handled with an optional attribute where if set, then the value is an array type. The value of this attribute should be either a positive integer or the string “Variable.” In every field definition, there needs to be a type string that is either “String,” “Float,” or “Int” which can be handled by a type
attribute. Finally, the name of each field is defined which can be handled by a name attribute.
Collection,Record,Key:String:destination,Key:String:product,Array:Int:Variable:Quantity
1 2 3 4 5
Figure 17. Module Input/Output String Definition Example Data Transformation Definition
The strings in figures 18, 19, and 20 show a few examples of how a transformation string is defined which, as a whole, cover all the different attributes and flags that make up a transformation string.
o In each figure, part ○1 defines the name of the transformation used. This
can be handled by a name attribute with an enumerated list of all possible transformations available.
o Part ○2 in Figure 18 and part ○3 in Figure 20 set different types of rounding
flags. The rounding can be “Round,” “Ceiling,” or “Floor” which map to the corresponding rounding function, with “Round” being the default. An optional rounding attribute can handle this with an enumerated list of the three type strings.
o Part ○2 of Figure 20 defines how the data should be handled (granularity) in
the transformation. The value here can be “Units,” “Sets,” “CurrentUnits,” or “CurrentSets.” This can be handled by another optional attribute with an enumerated list of strings.
o Part ○4 in Figure 20 gives an optional multiplier value by which the
transformed value is multiplied by before being sent to the destination. This can easily be handled by an optional multiplier attribute.
o Part ○3 of Figure 18 gives the index variable and a value associated with it.
Only a single index variable may be given per transformation. This can be handled by an optional index element where both a name and index value needs to be given if it is defined.
o Parts ○2 and ○3 of Figure 19 give field definitions. Some transformations
require one or more fields to be defined while others do not require any at all. This can be handled by an optional field element where there must be a name and value if a field is defined. This element must have [0..n]
multiplicity.
o Part ○4 in figures 18 and 19 and part ○5 in Figure 20 give the source
variable. Part ○5 in Figure 20 give optional starting and ending index values.
This can be handled with a mandatory source element with the attributes that represent the variable name, starting index, and ending index. The name is required, but starting and ending indices are optional.
o Part ○5 in figures 18 and 19 and part ○6 in Figure 20 give the target variable.
Like the source variable, starting and ending index values may also be provided. This can be handled with a mandatory target element that has a definition same as the source element.
FloatToInteger:Round,Index:period=0,quantity,Quantity
1 2 3 4 5
Figure 18. Data Transformation String Definition Example 1
FieldValueToVariable,Field:product=prodX,Field:Destination=route66,quantity,quantity
1 2 3 4 5
Aggregate:UNITS:Ceiling,Multiplier:10,quantity[1..5],quantity
1 2 3 4 5 6
Figure 20. Data Transformation String Definition Example 3 Control
The string in Figure 21 shows an example of how a control type string is defined.
o Part ○1 defines the type of control execution. In code, this value is saved,
but never used. To leave room for future development, it was decided that this entry should be used in the new design. This can be handled by an attribute that has a one value enumeration of “Periodic” for the current version of the KIB.
o Part ○2 was read in and ignored. This value has no meaning and will be
removed.
o Part ○3 gives the frequency value. This can be handled with an attribute
constrained to a positive, non-zero integer value.
Periodic:DEVSCYCLES:7
1 2 3
Figure 21. Control Type String Definition
3.2Using the KIB with the Inventory Strategy Module
Figure 1 above shows how the entire system was conceptualized at a high level. As stated in the problem, the Inventory Strategy Module (ISM) was a functional model, but was contained within an atomic model within DEVS. Since the ISM is built upon a different formalism, it makes sense to be a completely separate entity. Figure 22 shows how the ISM can be separated and the communication lines to be established through the KIB. The dashed lines show the communication that did not exist with
the previous design. There is a sequential order of communication and execution in this network:
1. Execute the SIM for one step
o For our model, “one step” means the length of time the LP will optimize over. This is usually over one week.
2. Transform data SIM => LP and SIM => ISM 3. Execute ISM
4. Transform data ISM => SIM and ISM => LP
o Communication from ISM back the SIM should only be used for transducer accumulation of data.
5. Execute LP
6. Transform LP => SIM
7. Repeat from step 1 until complete
SIM => LP LP => SIM SIM => ISM ISM => SIM ISM => LP ISM SIM (DEVS Suite) LP KIB
Figure 22. Separating ISM from SIM 3.3Development of KIB
Combining the KIB design premise described in 3.1.1 with the modularization of the ISM as described in 3.2, the code structure should then look like it does in Figure 23. Like before, DEVS, being the controlling model, starts the KIB through the DEVS
Interface. At each DEVS time tick, the time is updated in the KIB and, if it is time to do a transformation, the transformations and execution sequence in 3.2 is run. When transformations or executions in any of the interfaces are required, the interface object functions are called to perform the desired action. Once the sequence is complete, the resulting data is returned back to DEVS and the simulation continues.
KIB:SingleEchelonWeekly DEVS:SingleEchelon (Controlling Model) LP:SupplyChainDecision ISM:SupplyChainISM Calls
DEVS Interface (Data Return)
LP Interface (SupplyChainDecision Instance) ISM Interface (SupplyChainISM Instance) (Instantiates, Runs, Data Transform) (Instantiates, Runs, Data Transform) KIB_Relationship. xsd References Controlling Element KIB_Module.xsd KIB_Path.xsd
Operational Side Data Model Side (XML)
SingleEchelon DEVS Model
(Instance)
KIB_Control.xsd
Control
Frequency Execution Sequence
KIB
Figure 23. Interface Relationship with KIB 3.4Experimentation/Evaluation
Refactoring the XML schema must not disrupt the functionality of the KIB
OSF model’s KIB xml file will be re-written and the results will be tested to make sure the model produces the exact same data. On top of this, the previous unit tests must be rewritten and pass all execution pertaining to the KIB.
Some quantifiable measurements will test the scalability of the new KIB structure such as number of lines and number of elements. The new KIB design will then be used to develop a multi-echelon supply chain model. The ISM, being a new interface within the KIB, will be used to test the scalability of the KIB XML design when an addiction of an interface is required. The new XML schema and Java code must be easier to follow and manage. In other words, the design must make logical sense to one who is not familiar with the design.
XML code reuse is an important feature in any code design. As the KIB XML instance model is developed for the OSF platform, previous elements of the design that needs to be reused must be implemented without being rewritten.
There must be no post-process string parsing of the XML definition in Java code. All elements must be decomposed to their smallest atomic element within the XML schema. All constraints must be well documented.
A set of experiments will test the OSF system as a whole. The generation of meaningful experimental results shows that the entire system works with the new KIB and provides some data pertaining to the original goal to create a supply chain simulation model capable of running dynamic single and multiple echelon models. The run time scalability of the system should be tested to determine how feasible it will be to run models with thousands of components.
4 CONCEPT & XML DESIGN OF KIB 4.1File Decomposition
With the new design premise, the XML schema is decomposed into three separate components: the modules, transformation and a control. The KIB_Paths.xsd schema defines the paths to where each piece of the KIB model is defined. Figure 24 shows a graphical representation of the KIB_Paths.xsd schema. Within this schema, one or more paths need to be defined for each set of components with the exception of the control which requires exactly one path. The path must define another XML file with the correct pieces of the KIB model. The paths can be absolute or be relative to the location of the KIB_Paths instance. Any XML that is referenced here must begin with a KIBMODEL element which signifies that the file is part of the KIB model.
Figure 24. KIB_Paths.xsd Schema Graphic Representation
This design allows the entire KIB model to be decomposed into multiple parts and allow for partial definition in each file. This can greatly help out with development when the structures of the models stay the same, but the way they operate changes. For instance, with the supply chain model, when the discrete event simulator model changes from a weekly step size to a daily one and the LP model
still runs every week, the module definitions stay the same, but the transformations and control will change to accommodate this.
4.2Module Schema
The module component defined in KIB_Modules.xsd does two things: it ties an interface to a model name, and it defines a set of modules that belong to the model. Figures 25 and 26 show the graphical representation of the KIB_Modules.xsd schema.
Figure 25. KIB_Modules.xsd Schema Graphic Representation Level 1 4.2.1Model Element
Under the Model element, there are two attributes named ‘Name’ and ‘Interface’. The definition for ‘Name’ is a distinct name for the model within the KIB instance. This name is used as a referencing name to this model for the transformations definition. This name is also sent to the model interface in order to open the correct model. The definition for ‘Interface’ must be one of the enumerated values set
within code. Currently, this includes “DEVS,” “LP,” and “ISM.” This maps the distinct model name to an interface definition within code. Providing a unique model name for the interface allows a developer to create multiple models under the same interface. It also helps with labeling each component in the KIB.
4.2.2Module Element
Each model contains a set of modules. Under the Module element, there is a ‘Name’ attribute. The definition for ‘Name’ here is a distinct string name that references something within the model. This name is also referenced within the transformations definition. As Gary points out in his research, these modules can be seen as different things depending on the environment used (Gary 2008). Within DEVS, a module is closely tied to an atomic model component whereas within an LP the module does not hold much meaning.
4.2.3DataInput and DataOutput Elements
Each module has a set of input and output data lines associated with it. This would be the DataInput and DataOutput elements. Even though providing neither of these elements in a KIB XML would be semantically correct according to the schema, the module would serve no purpose. Therefore, a designer should always define at least one input or output. There is no difference between the schema definition of DataInput and DataOutput. The only difference is the way that they are treated within the KIB. A DataInput is used when data goes into the model and a
DataOutput is used when data comes out of the model. Under the DataInput and DataOutput elements is a ‘Name’ attribute which uniquely identifies the port and is also associated with something within the model instance.
4.2.4DataVariable Element
The type of data that is produced and consumed under a DataOutput or DataInput is defined as the DataVariable element. Each entry defines a column within a table. The DataVariable element contains the following attributes:
Name – label for the variable. The name must be distinct for the DataInput or DataOutput group.
Type - must be one of the following:
o String
o Int
o Float
IsKey – must either be “true” or “false” depending on if the variable is a key for the set. During runtime, there can never be two entries where all the key values are the same. This is similar to how a primary key set works in a
database. The newer set will overwrite the older set if all of the key values match. If no keys are set, the key is assumed to be ‘null’ for each incoming value and only the newest value set may be passed at each time step.
ArraySize – is an optional value. This is set if the data variable is an array field and signifies the size of the array. This value must be a positive integer value greater than 0 or the string “Variable” if the size of the array is unknown.
4.3Control Schema
The control schema defines frequency and the order of the transformation actions. Figure 27 shows the graphical representation of the KIB_Control.xsd schema.
Figure 27. KIB_Control.xsd Schema Graphical Representation 4.3.1Control Element
Within the Control element are the following attributes:
Model
Module
o Defines the name of the module under the previously defined model which contains the controlling variable
DataOutput
o Defines the name of the data output under the previously defined module which contains the controlling variable
DataVariable
o Defines the name of the data variable under the previously defined data output which is the controlling integer variable
Type
o Can only be set to the string “Periodic” for the current version of the KIB. This signifies that transformations happen periodically. Future
developments of the KIB may allow for other options.
Frequency
o Must be an integer value greater than 0 which defines how often the non-controlling model elements be executed – For instance, if this value is set to 2, execution will occur at instances 0, 2, 4, and so on until the model
terminates.
4.3.2Execution Element
A single Execution element must be defined under the Control element. The Execution element gives the order of execution models to run at the frequency instances. One or more Run elements must be defined under the Execution element and order of given elements is crucial. For each Run element that is defined, the Model attribute should give the name of the model to execute. The model name
must be previously given elsewhere within the KIB modules definitions and cannot be the model that is defined as the controlling model.
4.4Relationship Schema
The relationship schema provides the structure and constraints of the transformation definitions. Figures 28, 29, 30, and 31 show the graphical representation of the KIB_Relationship.xsd schema.
Figure 28. KIB_Relationship.xsd Schema Graphic Representation Level 1 4.4.1Relationship Element
A single Relationship element signifies that this is an XML that defines the relationships of the KIB model.
4.4.2Map Element
One or more Map elements must be defined under the Relationship element. The Map element defines a mapping between a DataOutput of one Module to a DataInput of another Module. The ‘Interval’ and ‘IntervalOffset’ attributes within the Map element define when all the transformations within a mapping should take place. These values are relative to the control frequency that is defined above in 4.3. The ‘Interval’ defines how often to execute this mapping transformation. This must be a positive, non-zero integer value. For example, if the frequency in the control is
set to 7 and the interval here is set to 2, the mapping will be executed on 0, 14, 28, and so on until the system terminates. The ‘IntervalOffset’ defines at what time the first transformation is executed. This must be a non-negative integer value. For example, taking the above case where frequency set to 7 and interval of mapping set to 2, if the interval offset is set to 5, the mapping will be executed on 5, 19, 33, and so on until the system terminates.
Figure 29. KIB_Relationship.xsd Schema Graphic Representation Level 2 4.4.3Source DataOutput Element
Under each Map element is a Source element. The Source element contains the attributes ‘Model’, ‘Module’, and ‘Data’ which correspond to the names of a Model, Module, and DataOutput that has been previously defined. This makes up the address of a DataOutput element.
4.4.4Target DataInput Element
Under each Map element is also a Target element. The definition of a Target element is the same as the Source element. The only distinction is that the ‘Data’ attribute references a DataInput element.
Figure 30. KIB_Relationship.xsd Schema Graphic Representation Level 3 4.4.5Transformation Element
At least one Transformation definition must be given for each mapping. A
Transformation element defines how data shall be transformed at the execution of this mapping within the KIB. The order of transformations does not make any different in the end result. Within the ‘Name’ attribute is an enumeration of
execution object. This name may be one of the names given in the list below. For a deeper explanation of each of these transformations, refer to APPENDIX B.
NONE COPY IntegerToFloat FloatToInteger Aggregate MAX MIN MEDIAN MEAN NewestValue OldestValue SET_TO_VALUES VALUES_TO_SET FieldValueToVariable VariableToFieldValue ASSIGN_FIELD_VALUES DisaggregateIntoEqualBuckets AllToOneValue AllCurrentToOneValue
The attribute ‘Rounding’ defines how to round the data before it is transformed. If the source value is already an integer value, any of the rounding