Advanced logistics analysis capabilities environment

The different advantageous embodiments provide a system for modeling supply chain networks comprising a model manager, a node manager, a pipeline manager, a requisitions manager, and a supply control manager. The model manager is configured to initialize a model. The node manager is configured to initialize a number of nodes within the model. The pipeline manager is configured to generate a number of pipeline data objects describing supply chain relationships between a number of nodes. The requisitions manager is configured to generate and receive requests for supplies. The supply control manager is configured to send and receive supplies according to requests for supplies.

BACKGROUND INFORMATION

The present disclosure relates generally to a data processing system and more particularly to supply chain networks. Still more particularly, the present disclosure relates to analysis and modeling to predict supply chain performance in a supply chain network.

Operational and support costs of military and commercial aircraft systems typically make up the majority of total ownership costs a customer pays over the life of a system, from initial design to retirement. Design and procurement typically make up the other minority of total ownership costs. Suppliers and customers are increasingly concerned with reducing logistics and operational support costs of products and services, while at the same time assuring required operational and system availabilities levels are met.

Performance-based logistics contracts are increasingly replacing traditional transaction based contracts as a means to improving efficiency and reducing overall costs, holding the service provider responsible for meeting performance measures as negotiated by contract. Under these types of agreements, incentives are paid to the service provider for exceeding required performance levels and penalties are imposed when performance metrics are not met.

Modeling, simulation, and analysis tools provide a means of identifying, assessing, and predicting system performance and associated levels of risk prior to entering contracts. Existing tools focus on inventory stocking level optimization and are limited to supply chain specific aspects of products and services. These tools include a high product cost, and are complex and time-intensive to set up and execute.

Therefore, it is advantageous to have a method and apparatus that takes into account one or more of the issues discussed above, as well as possibly other issues.

SUMMARY

One or more of the different advantageous embodiments provide a system for modeling supply chain networks comprising a model manager, a node manager, a pipeline manager, a requisitions manager, and a supply control manager. The model manager is configured to initialize a model. The node manager is configured to initialize a number of nodes within the model. The pipeline manager is configured to generate a number of pipeline data objects describing supply chain relationships between a number of nodes. The requisitions manager is configured to generate and receive requests for supplies. The supply control manager is configured to send and receive supplies according to requests for supplies.

The different advantageous embodiments further provide a method for modeling supply chain networks. A model is initialized using a model manager. A core database is generated using the model manager. A number of nodes is generated within the model using a number of code objects. A number of pipeline data objects configured to describe supply chain relationships between the number of nodes within the model is generated. A simulation is run using the model to analyze the supply chain relationships. The different advantageous embodiments further provide a method for defining a procurement relationship for replenishing supplies. A pipeline is created for a first node. The pipeline comprises a definition specifying simulation times at which the pipeline is to be evaluated. The pipeline is recorded in a node database for the first node. The pipeline is evaluated according to the definition. A supply requisition is generated based on the evaluation of the pipeline. The supply requisition is transmitted to a second node using a token.

DETAILED DESCRIPTION

Referring more particularly to the drawings, embodiments of the disclosure may be described in the context of aircraft manufacturing and service method100as shown inFIG. 1and aircraft200as shown inFIG. 2. Turning first toFIG. 1, an illustration of an aircraft manufacturing and service method is depicted in accordance with an advantageous embodiment. During pre-production, aircraft manufacturing and service method100may include specification and design102of aircraft200inFIG. 2and material procurement104.

During production, component and subassembly manufacturing106and system integration108of aircraft200inFIG. 2takes place. Thereafter, aircraft200inFIG. 2may go through certification and delivery110in order to be placed in service112. While in service by a customer, aircraft200inFIG. 2is scheduled for routine maintenance and service114, which may include modification, reconfiguration, refurbishment, and other maintenance or service.

With reference now toFIG. 2, an illustration of an aircraft is depicted in which an advantageous embodiment may be implemented. In this example, aircraft200is produced by aircraft manufacturing and service method100inFIG. 1and may include airframe202with a plurality of systems204and interior206. Examples of systems204include one or more of propulsion system208, electrical system210, hydraulic system212, environmental system214, and thermal system216. Any number of other systems may be included. Although an aerospace example is shown, different advantageous embodiments may be applied to other industries, such as the automotive industry.

Apparatus and methods embodied herein may be employed during at least one of the stages of aircraft manufacturing and service method100inFIG. 1. As used herein, the phrase “at least one of”, when used with a list of items, means that different combinations of one or more of the listed items may be used and only one of each item in the list may be needed. For example, “at least one of item A, item B, and item C” may include, for example, without limitation, item A or item A and item B. This example also may include item A, item B, and item C or item B and item C.

In one illustrative example, components or subassemblies produced in component and subassembly manufacturing106inFIG. 1may be fabricated or manufactured in a manner similar to components or subassemblies produced while aircraft200is in service112inFIG. 1. As yet another example, a number of apparatus embodiments, method embodiments, or a combination thereof may be utilized during production stages, such as component and subassembly manufacturing106and system integration108inFIG. 1. A number, when referring to items, means one or more items. For example, a number of apparatus embodiments is one or more apparatus embodiments. A number of apparatus embodiments, method embodiments, or a combination thereof may be utilized while aircraft200is in service112and/or during maintenance and service114inFIG. 1. The use of a number of the different advantageous embodiments may substantially expedite the assembly of and/or reduce the cost of aircraft200.

The different advantageous embodiments recognize and take into account a number of different considerations. For example, the different advantageous embodiments recognize and take into account that current tools for modeling supply chain performance generally are purchased from a vendor, operate at less level of detail than desired, and typically focus on inventory stocking level optimization. Some current tools use a multi-step, iterative, marginal analysis procedure to determine optimum stocking levels. Other current tools use risk-based algorithms and forecasting to determine optimum stocking levels. Still other current tools use mixed-integer/linear programming combined with a proprietary discrete-event simulation engine to determine optimum stocking levels.

The different advantageous embodiments further recognize and take into account that current tools use analytical methods to solve inventory optimization problems and provide guidance as to recommended inventory levels. These current tools have a high product cost, are complex and time-intensive to set up and execute, and have limited or non-existing capabilities to model non-supply chain specific aspects of a total system architecture.

The different advantageous embodiments further recognize and take into account that current supply chain modeling tools are expensive and complex to set up and run, and lack the capability to easily expand the scope of the simulation to model lower level details about a system design. These limitations create burdens for concept analysts, system engineers, and logistics analysts, who may need to construct a model to analyze and predict supply chain performance, while also addressing aspects of the system impacted by the supply chain, such as maintenance requirements, resource requirements, manufacturing requirements, transportation system design requirements, and the like.

Thus, one or more of the different advantageous embodiments provide a system for modeling supply chain networks comprising a model manager, a node manager, a pipeline manager, a requisitions manager, and a supply control manager. The model manager is configured to initialize a model. The node manager is configured to initialize a number of nodes within the model. The pipeline manager is configured to generate a number of pipeline data objects describing supply chain relationships between a number of nodes. The requisitions manager is configured to generate and receive requests for supplies. The supply control manager is configured to send and receive supplies according to requests for supplies.

The different advantageous embodiments further provide a method for modeling supply chain networks. A model is initialized using a model manager. A core database is generated using the model manager. A number of nodes is generated within the model using a number of code objects. A number of pipeline data objects configured to describe supply chain relationships between the number of nodes within the model is generated. A simulation is run using the model to analyze the supply chain relationships. The different advantageous embodiments further provide a method for defining a procurement relationship for replenishing supplies. A pipeline is created for a first node. The pipeline comprises a definition specifying simulation times at which the pipeline is to be evaluated. The pipeline is recorded in a node database for the first node. The pipeline is evaluated according to the definition. A supply requisition is generated based on the evaluation of the pipeline. The supply requisition is transmitted to a second node using a token.

Turning now toFIG. 3, a diagram of a data processing system is depicted in accordance with an illustrative embodiment. Data processing system300may be used to implement processes for modeling supply chain networks in one or more different advantageous embodiments. In this illustrative example, data processing system300includes communications fabric302, which provides communications between processor unit304, memory306, persistent storage308, communications unit310, input/output (I/O) unit312, and display314.

Processor unit304serves to execute instructions for software that may be loaded into memory306. Processor unit304may be a set of one or more processors or may be a multi-core processor, or multiple central processing units (CPUs), depending on the particular implementation. Further, processor unit304may be implemented using one or more heterogeneous processor systems, in which a main processor is present with secondary processors on a single chip. As another illustrative example, processor unit304may be a symmetric multi-processor system containing multiple processors of the same type.

Memory306and persistent storage308are examples of storage devices316. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Memory306, in these examples, may be, for example, a random access memory, or any other suitable volatile or non-volatile storage device. Persistent storage308may take various forms, depending on the particular implementation. For example, persistent storage308may contain one or more components or devices. For example, persistent storage308may be a hard drive, flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage308may be removable. For example, a removable hard drive may be used for persistent storage308.

Communications unit310, in these examples, provides for communication with other data processing systems or devices. In these examples, communications unit310is a network interface card. Communications unit310may provide communications through the use of either or both physical and wireless communications links.

Input/output unit312allows for the input and output of data with other devices that may be connected to data processing system300. For example, input/output unit312may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, input/output unit312may send output to a printer. Display314provides a mechanism to display information to a user.

Instructions for the operating system, applications, and/or programs may be located in storage devices316, which are in communication with processor unit304through communications fabric302. In these illustrative examples, the instructions are in a functional form on persistent storage308. These instructions may be loaded into memory306for execution by processor unit304. The processes of the different embodiments may be performed by processor unit304using computer implemented instructions, which may be located in a memory, such as memory306.

These instructions are referred to as program code, computer usable program code, or computer readable program code that may be read and executed by a processor in processor unit304. The program code, in the different embodiments, may be embodied on different physical or computer readable storage media, such as memory306or persistent storage308.

Program code318is located in a functional form on computer readable media320that is selectively removable and may be loaded onto or transferred to data processing system300for execution by processor unit304. Program code318and computer readable media320form computer program product322. In one example, computer readable media320may be computer readable storage media324or computer readable signal media326. Computer readable storage media324may include, for example, an optical or magnetic disc that is inserted or placed into a drive or other device that is part of persistent storage308for transfer onto a storage device, such as a hard drive, that is part of persistent storage308. Computer readable storage media324also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory that is connected to data processing system300. In some instances, computer readable storage media324may not be removable from data processing system300.

Alternatively, program code318may be transferred to data processing system300using computer readable signal media326. Computer readable signal media326may be, for example, a propagated data signal containing program code318. For example, computer readable signal media326may be an electro-magnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communications links, such as wireless communications links, an optical fiber cable, a coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In some illustrative embodiments, program code318may be downloaded over a network to persistent storage308from another device or data processing system through computer readable signal media326for use within data processing system300. For instance, program code stored in a computer readable storage media in a server data processing system may be downloaded over a network from the server to data processing system300. The data processing system providing program code318may be a server computer, a client computer, or some other device capable of storing and transmitting program code318.

As another example, a storage device in data processing system300is any hardware apparatus that may store data. Memory306, persistent storage308, and computer readable media320are examples of storage devices in a tangible form.

With reference now toFIG. 4, an analysis environment is depicted in accordance with an advantageous embodiment. Analysis environment400may be implemented during aircraft manufacturing and service method100inFIG. 1, for example. In an illustrative example, analysis environment400may be implemented during specification and design102inFIG. 1of aircraft200inFIG. 2, material procurement104, and/or routine maintenance and service114inFIG. 1.

Analysis environment400may include computer system401. Computer system401may be a stand alone computer or a number of computers in a network. Computer system401includes number of computers403. As used herein, “number of” refers to one or more computers. Each computer in number of computers403may be implemented using data processing system300inFIG. 3, for example.

User402may be, for example, without limitation, a human, intelligent agent, autonomous agent, web services, and/or any other suitable operator of analysis system404. Analysis system404may be implemented using computer system401. Analysis system404includes user interface406and number of code objects408. User interface406may include display410, worksheet412, and drag and drop feature414. User402may access number of code objects408via user interface406, using drag and drop feature414to select and place number of code objects408onto worksheet412, which generates model416.

Model416represents a model constructed on worksheet412using number of code objects408. Model416is a set of assumptions about the behavior of a system of interest, such as a supply chain network. Model416may take the form of mathematical or logical relationships. Model416is capable of running as a simulation. Number of code objects408is a collection of one or more fully compiled, self-contained, blocks of code. Number of code objects408may include auto-build macros that automatically generate data structures and/or data objects. When a code object in number of code objects408is selected for addition to model416, an instance of the code object is placed into model416. Model416includes model manager418. Model manager418is the initial code object from number of code objects408selected and placed into worksheet412. Model manager418includes model setup macro420and database generator422.

When model manager418is dragged onto worksheet412, model setup macro420initiates to prepare model416for receiving additional code objects and initiates database generator422. Database generator422creates plurality of databases424. Plurality of databases424may include core database426, calculation work database428, and results database430. Database generator422imports stored text files from storage432to create plurality of databases424.

Core database426is a global database for model416that is automatically generated when initializing model416with model manager418. Core database426includes data structure definitions and parent lists for all other databases that may be generated in model416, such as number of node databases454. When node444is added to model416, node setup macro456initiates to prepare node444for receiving additional code objects and initiates node database generator458. Node database generator458automatically adds a node database to number of node databases454for each node generated, such as node database460for node444in this illustrative example. Each node database in number of node databases454includes the data structure to contain detailed information for one associated node, such as pipeline definitions, sent and received requisitions, supply release or shipments, and runtime results. A pipeline is a defined procurement relationship or strategy for replenishment of supplies. If a node is deleted from a model, such as model416, the corresponding node database is also deleted. The definition detail for a node database is stored in core database426. Core database426also includes data structures for detailed identification, status, and runtime information for each node in number of nodes442.

Core database426may include node identification434, node types436, node database descriptions438, token log440, and other suitable database elements. Node identification434may be a table of unique node identification strings, or unique node names. Node types436is a list of pre-defined node types. Node database descriptions438includes information on database structure for nodes. Token log440is a list of stored tokens. A token is a data artifact created for each transaction in a simulation.

Results database430includes a collection of runtime node transaction records and summary results designed to be exported for post processing. Results database430is added with model manager418during initialization of model416. The data in results database430is refreshed at the end of each simulation run for model416. The definition detail for results database430is also stored in core database426.

Calculation work database428is an exposed runtime data structure used by requisitions managers, such as requisitions manager450, to determine how much supply is needed and from which node the supplies are to be requisitioned. Calculation work database428is added with model manager418during initialization of model416. Individual tables are added to calculation work database428for each pipeline that is created within model416by pipeline managers, such as pipeline manager448. The definition detail for calculation work database428is also stored in core database426.

Number of nodes442represents unique locations where inventory assets are created, stored, sold, and/or replenished. Number of nodes442may be, for example, a number of inventory control points. Number of nodes442is a collection of one or more named objects that can be added already configured from model autobuild macros. Number of nodes442may be added and modified to model416either manually by a user, such as user402, or automatically by a script. Each node in number of nodes442can be added and modified to model416with fully isolated objects and data constructs, without affecting other nodes in model416. Number of nodes442each has a unique identification string, or name, registered by node setup macro456at the time of node creation with core database426in node identification434. Node444is an illustrative example of number of nodes442.

Node444includes node identification manager446, node setup macro456, node database generator458, pipeline manager448, requisitions manager450, supply control manager452, and number of node databases454. Node identification manager446, pipeline manager448, requisitions manager450, and supply control manager452may be illustrative examples of code objects from number of code objects408placed within node444using worksheet412. Each code object within a node, such as node identification manager446, pipeline manager448, requisitions manager450, and supply control manager452in node444, references other node data structures within number of nodes442when setting and defining attributes and/or policies and when generating transactions during runtime of model416. These attributes and policies are stored in number of node databases454.

When a code object is selected to add to a model, the code object checks that the global and local environment is correct. If the environments are not correct, the block will not be added to the model. The global environment is the model environment, such as model416. The local environment is the node environment, such as node444, for example. In an illustrative example, if pipeline manager448is the first code object to be selected for addition to model416, pipeline manager448will check the local and global environment and determine that model manager418is not present, and therefore pipeline manager448cannot be added.

In another illustrative example, if pipeline manager448is selected for addition to model416and pipeline manager448determines that model manager418is present in the global environment, but node identification manager446is not present in the local environment of node444, pipeline manager448will not be added. In yet another illustrative example, if pipeline manager448is selected for addition to model416and pipeline manager448determines that model manager418is present in the global environment and node identification manager446is present in the local environment of node444, pipeline manager448will be added to node444.

When node identification manager446, is added to model416, node identification manager446locates and obtains global data structure information from core database426. The global data structure information is used to register the local code object, such as node identification manager446, in the global data structure. A dialog box may be presented via user interface406to user402asking for a unique node identification string, or name, and the block addition will not continue until the name entered is unique. After a unique name is entered, the dialog box may ask user402to select a node type from a list of pre-defined node types, such as the node types stored in node types436of core database426. Node identification manager446then recalls a description of the required local node data structure from node database descriptions438of core database426and builds the local node data structure based on the description recalled. Node444may be initialized with global data structures from core database426, with records added to core database to store indexes of node444. In this way, each node in number of nodes442comprises an identical data structure.

When a node or code object is deleted from model416, node identification manager446clears related node records from other node databases in number of node databases454and core database426. Node identification manager446will also delete all local data structures for the deleted node or code object from model416and reset the global references for remaining nodes in number of nodes442.

Pipelines are data objects associated with any number of nodes in a supply chain simulation, which define a procurement relationship or strategy for replenishing supplies. Each pipeline, or pipeline data object, is a data record in an expandable table of records. Each node may have an unlimited number of supply chain relationships described by pipeline data objects. Pipeline manager448generates number of pipeline data objects455. Number of pipeline data objects455for node444may be stored within node database460, for example. Number of pipeline data objects455is configured to specify individual supply chain relationships between number of nodes442. A set of one or more pipeline data objects from number of pipeline data objects455may describe a complete supply chain network, for example. Each relationship within a supply chain network may have a different set of properties, including which parts are involved, when ordering should occur, replenishment policies, and so on. Model code objects, such as pipeline manager448, requisitions manager450, and supply control manager452, for example, are configured to work with number of pipeline data objects455.

For example, plurality of databases424may include additional database, such as a forecast database. A forecast database may be added when a simulation scenario is utilizing forecasts as selected as an option in model manager418. The forecast database includes an exposed data structure that is used when populating the node forecast tables. The definition detail for the forecast database is stored in core database426.

With reference now toFIG. 5, a number of code objects is depicted in accordance with an advantageous embodiment. Number of code objects500is an illustrative example of one implementation of number of code objects408inFIG. 4.

Number of code objects500may include, for example, without limitation, model manager502, database sync shadows504, node506, node forecast demand508, node identification manager510, node pipeline manager512, node requisitions manager514, node supply control manager516, mail slot manager518, other code objects520, token functions522, and/or any other suitable object.

Model manager502is the first code object, or block, placed into a model, such as model416inFIG. 4. No other code objects from number of code objects500can be placed into a model without first having model manager502in the model. When model manager502is added, it guides the user, such as user402inFIG. 4, through a setup macro, such as model setup macro420inFIG. 4.

Database sync shadows504is a code object that maintains common, or parent, type and list tables between databases by identifying one database as the core database. Database sync shadows504synchronizes all common fields between core database tables and identical shadow tables in all other databases.

Node506is unique location where inventory assets are created, stored, sold, and replenished. Node506may be referred to, for example, as an inventory control point in a supply chain modeling simulation.

Node forecast demand508is an optional code object designed to support models that are driven by forecast tables. Node forecast demand508can function as a simple top-level demand block during runtime, plus support multi-tiered forecast models by automating the task of building lower tier forecast tables based on pipeline definitions. Node forecast demand508is used in models where a forecast tables option was selected in model manager502during the setup macro.

Node identification manager510is the first block required to be placed in a node. When node identification manager510is added, it sets off a setup macro that creates a node database. Node identification manager510provides other node blocks, such as node pipeline manager512, node requisitions manager514, and node supply control manager516, with identification parameters needed during configuration and runtime.

Node pipeline manager512provides the dialog used to configure and modify pipelines within a model. Node pipeline manager512maintains database pipeline tables and records to store information about each pipeline in a node. A pipeline is a defined procurement relationship or strategy for replenishment of supplies.

Node requisitions manager514is a runtime block that takes the timing, rules, and supply position calculations configured in each pipeline and releases replenishment requisitions based on the results. These transactions are recorded by node requisitions manager514in the local node database.

Node supply control manager516is a runtime block that takes requisitions received by the node and releases available supplies, or shipments. Node supply control manager516also receives supplies that are arriving at the node. Node supply control manager516records supply release and deliveries in the local node database.

Mail slot manager518is an optional messaging code object for custom model constructs that surround a model. Other code objects520may include statistics, needs repair logger, preconfigured node modules, and/or any other suitable code objects.

Token functions522provide a way of exposing communications between model entities, such as code objects, via the database so that the communications are more visible and can be operated on directly. Token functions522include generic properties that allow for unlimited number of custom logics for supply chain related decisions. Token functions522are stored in a token log of the core database, such as token log440inFIG. 4, during runtime. Token functions522can initiate different behaviors in the model depending upon the token type and token mode, discussed in more detail inFIG. 6.

With reference now toFIG. 6, a token log is depicted in accordance with an advantageous embodiment. Token log600is an illustrative example of one implementation of token log440inFIG. 4.

Token log600includes data object attributes that describe the purpose and function of a given token. Node source602lists possible nodes a token may have initiated from, such as node A604and/or node B606. Node destination608lists possible nodes a token may be intended for, such as node A610and/or node B612. In one advantageous embodiment, node A604and node B606may be the same node.

Token type614lists different types of tokens that may be generated, such as push requisition616, pull requisition618, supply release620, adhoc pull where622, adhoc pull quantity624, adhoc pull priority626, adhoc push where628, adhoc push quantity630, adhoc push priority632, animation634, and/or any other suitable type of token. Each token's objective and intended use may be described in a data record stored in the core database, for example.

Push requisition616notifies a receiver of impending shipment of pushed parts. Push is a requisition type that describes one node sending supplies to other nodes or a local assembly/refurbish resource based on the sending node's local inventory position. Pull requisition618notifies a vendor of an order for parts. Pull is a requisition type that describes one node requesting supplies from another node or a local assembly/refurbish resources based on the receiving node's local inventory positions. Supply release620sends parts to a receiver, such as a shipment to fulfill an order or request for supplies.

Adhoc is a requisition type that dynamically determines the replenishment source and/or quantity during runtime. An internal adhoc requisition uses a predefined list of adhoc types stored in a pipeline dialog generated by a pipeline manager, such as pipeline manager448inFIG. 4, for example. An external adhoc requisition releases a token into custom modeling constructs to determine the replenishment source, priority, delivery delay and/or quantity of supplies needed. Adhoc pull where622calculates where an order is originating from. Adhoc pull quantity624calculates a quantity to order. Adhoc pull priority626calculates an order priority. Adhoc push where628calculates where to send pushed parts. Adhoc push quantity630calculates a quantity of pushed parts to send. Adhoc push priority632calculates a priority of pushed parts. Animation634triggers an animation to go with a supply release.

Token mode636may describe a mode for a token. The token mode is a reference for the runtime messaging method that was utilized to release and/or communicate the token.

Node source reference638indicates which node is the source node for the token. Date/Time issued640provides a reference date and time for the token issue. Date/Time received or returned642provides a reference date and time for completion of the token. Status644describes the status of a particular token, such as en route/calculation646, received/closed648, lost650, and/or any other suitable token status.

Attribute A652, attribute B654, attribute656are context dependent data files that may be used to store data related to tokens.

With reference now toFIG. 7, a token architecture is depicted in accordance with an advantageous embodiment. Token architecture700is an illustrative example of the relationship between tokens and code objects in analysis environment400ofFIG. 4.

Token architecture700may include code object B702and code object A704. Code object B702and code object A704are illustrative examples of one implementation of number of code objects408inFIG. 4. In this illustrative example, code object B702has a need to send data or pass control to another model object, such as code object A704. In one illustrative example, code object B702may be a supply control manager that needs to ship an order to another node, such as code object A704.

In this illustrative example, token706is generated and stored in core database708for access by the model. Token attributes for token706specify which model object sent the token, which model object is meant to receive token706, and where related data is stored in node database710and calculation work database712.

If custom logic714is invoked to more fully describe the behavior being modeled, the token mode for token706is set to “local con out” or “mail slot,” which pass the token record identification information to the custom code the user provides. When the user provided custom logic714receives the new token record identification number, custom logic714can look up specific attributes of token706in core database708.

Node database710includes data needed for user provided custom logic714to execute. This data is context sensitive data which depends on the type, or purpose, of token706. For example, data in the supply release table may indicate how many items need to be shipped for a particular order.

Calculation work database712stores results of custom logic714needed by the receiving model object, in this example code object A704. When custom logic714completes its calculations, custom logic714passes token record identification information to code object A704. Code object A704then kicks off baseline functionality associated with receiving a token of that type, such as putting parts in inventory for example. If additional calculated data is required to complete baseline functionality, code object A704can locate that data in calculation work database712.

With reference now toFIG. 8, a pipeline architecture is depicted in accordance with an advantageous embodiment. Pipeline architecture800is an illustrative example of the relationship between data objects and code objects in analysis environment400ofFIG. 4.

Pipelines are data objects associated with any number of nodes in a supply chain simulation, which define a procurement relationship or strategy for replenishing supplies. Each pipeline is a data record in an expandable table of records. Each node may have an unlimited number of supply chain relationships described by pipeline data objects. A pipeline data object, such as number of pipeline data objects455inFIG. 4for example, is configured to specify individual supply chain relationships between nodes, such as number of nodes442inFIG. 4. A set of pipeline data objects, such as number of pipeline data objects455inFIG. 4, may describe a complete supply chain network. Each relationship may have a different set of properties, including which parts are involved, when ordering should occur, replenishment policies, and so on. Model code objects, such as pipeline manager448, requisitions manager450, and supply control manager452inFIG. 4, for example, are configured to work with pipeline data objects.

In an illustrative example, requisitions manager450inFIG. 4is configured to generate requisitions for parts at the appropriate times in the simulation in accordance with rules defined by each pipeline. The segregation of pipeline attributes from requisitions manager450inFIG. 4enables requisitions manager450to be generic and identical between each node in a model, such as node A802and node B804, for example. The data that describes the supply relationships may change dynamically, but the node and the code objects within a node may be static and reusable. Changing the supply chain network is also straightforward, accomplished by editing the pipeline relationships.

In this illustrative example of pipeline architecture800, there are two nodes, node A802and node B804, each with their own local database. When node A802and node B804are created in the model, such as model416inFIG. 4, the associated node A database806and node B database808are also created. Node A database806is the local database for node A802. Node B database808is the local database for node B804. Each local database provides tables for describing pipelines that are defined for the local node. For example, node A database806includes tables describing pipelines that are defined for node A802. These tables are empty until a pipeline is defined using either a user interface, such as user interface406inFIG. 4, or a script.

Node A802includes pipeline manager810, requisitions manager812, and supply control manager814. Pipeline manager810, requisitions manager812, and supply control manager814are illustrative examples of one implementation of number of code objects408inFIG. 4. Node B804includes pipeline manager816, requisitions manager818, and supply control manager820.

Pipeline manager810and pipeline manager816are configured to create, modify, and delete pipelines in order to describe supply chain relationships. When a new pipeline is created, the pipeline manager for the source node adds a record to the node database of the source node. If the pipeline specifies a static link to a partner node, the pipeline manager for the partner node adds a reference to the source node in the node database of the partner node. This enables each node in a supply chain simulation to have knowledge of which other nodes the node has a supply replenishment relationship with in the model.

Requisitions manager812and requisitions manager818are configured to work with defined pipelines to post orders for parts. The requisitions manager evaluates inventory status at the timing specified in the pipeline definition. The parts to order, if any, are calculated by the requisitions manager according to the policies described by each pipeline.

Supply control manager814and supply control manager820are configured to receive requisitions and release available supplies. If a supply is not available, the supply control manager will increment a “supply current requisitions” field in the local node database supply position table to document the backlog. New supplies cannot be ordered until an appropriate pipeline is evaluated to decide to order the replenishment parts. The supply control manager also receives incoming shipments and increments local inventory accordingly.

Each local database includes a number of tables and information about pipelines, nodes, and the relationship between nodes. Node A database806includes pipelines originating here822, pipelines linked to here824, requisitions sent826, requisitions received828, supply position830, and supply release832. Pipelines originating here822is a table describing each supply relationship initiated by node A802. When a new pipeline is generated by pipeline manager810of node A802, the pipeline is recorded in pipelines originating here822. Pipelines originating here822is referenced by requisitions manager812during runtime.

Pipelines linked to here824is a reference table of each supply relationship linked to node A802but originating from a node other than node A802. Requisitions sent826is a table of orders or requests for supplies originating from node A802. These orders or requests can be between different nodes, or within the same node if assembling or refurbishing supplies, for example. Requisitions received828is a table of orders or requests for supplies received by node A802. Supply position830tracks the state of supplies within node A802. All supplies are tracked in one of two states, a fully functional supply that is known as “supply” and the same non-functioning supply inventoried as “needs repair.” Supply position830also tracks the quantity of supplies in inventory at node A802. Supply release832is a table tracking the shipment or release of supplies from node A802.

Supply chain relationships may be defined by creating pipeline data objects. This definition can be performed via a user interface provided by the pipeline model object, such as user interface406inFIG. 4, for example. The user interface allows for the creation, modification, and deletion of pipelines in a model. However, since the data that describes each pipeline is entirely contained in each node's local data, pipeline architecture800is also capable of creating pipelines via automation.

In this illustrative example, pipeline manager810in node A802creates pipeline846. Pipeline846is recorded in pipelines originating here822. New link848is created between node A802and node B804and recorded in pipelines linked to here836of node B database808. Pipeline846includes a definition specifying the simulation times at which pipeline846should be evaluated for possible creation of a supply requisition. Definition850is referenced by requisitions manager812from pipelines originating here822.

Requisitions manager812is capable of evaluating the local supply position of node A802in accordance with definition850. Requisitions manager812generates supply requisition852and transmits order852to a vendor node, such as node B804in this example. The transfer of the order from node A802to node B804is accomplished via token854. Node B requisition manager818receives token854and processes order852. Supply requisition852is recorded in requisitions sent826of node A database806.

Requisitions manager818receives token854and records requisition856in requisitions received840. Supply control manager820monitors requisitions received840and pulls requisition received858to attempt to fill orders with parts in node B804inventory. When the order is capable of being filled, supply control manager820sends shipment860to supply control manager814of node A802. Supply control manager820records shipment860in supply release844of node B database808, and decrements local inventory accordingly in supply position842. Supply control manager820sends token861to supply control manager814indicating a shipment has been released. Supply control manager814of node A802receives shipment860and sends update862to supply position830to increment local inventory accordingly.

With reference now toFIG. 9, a user interface is depicted in accordance with an advantageous embodiment. User interface900is an illustrative example of one implementation of user interface406inFIG. 4. User interface900depicts pipeline manager dialog902in this illustrative example. Pipeline manager dialog902may run in response to addition of pipeline manager448to model416inFIG. 4, for example. Pipeline manager dialog902may also be pulled up during a simulation to create, modify, or delete a pipeline.

Pipeline manager dialog902depicts tabs including originating pipelines904, linked pipelines906, create/modify pipelines908, results910, and comments912. Originating pipelines904provides access to a pipelines originating here database table, such as pipelines originating here822inFIG. 8, for example. Linked pipelines906provides access to a pipelines linked to here database table, such as pipelines linked to here824inFIG. 8. Create/modify pipelines908provides configurable options to create, modify, or delete a pipeline. Results910provides a window to output statistics gathered for all pipelines originated by the node associated with pipeline manager dialog902. Comments912is a place for an analyst, such as user402inFIG. 4, to place configuration notes.

In this illustrative example, create/modify pipelines908is selected. Node record914, node ID block number916, node database index918, and node name920are each read-only parameters that reveal the registration values and name for the node. Mode selection922allows a user, such as user402inFIG. 4, to select the type of pipeline that is being saved with actionable macro buttons. The type of pipeline may be, for example, without limitation, a template or a node.

Pipeline ID924is a read-only parameter that reveals the unique string identification assigned to the pipeline when it is created. User Description926allows a user to input relevant notes to the pipeline definition. Priority rule928is an input selection for setting the priority of requisitions, with higher priority requisitions being serviced first. Start Date930sets the runtime calendar date when the requisitions manager begins evaluation. The start date for the pipeline evaluation can be further adjusted by the First Check Date/Time934which provides increased precision for the Cycle Check936setting. Cycle Check936sets the amount of simulation time that will pass between requisition manager evaluations of the pipeline. For example, cycle check936may provide options such as, without limitation, once a day, once a week, once a month, and/or any other suitable amount of time. End Date932sets the runtime calendar date when the requisitions manager stops evaluation. Supply Strategy938is a selection of a single high-level replenishment strategy being defined. The selection of a supply strategy938in combination with the Sourcing Rule Selection of Pull or Push covers the core matrix of replenishment relationships that are defined in supply chain simulations. In this example Supply Strategy938has been set to a Release Supply, Deliver Supply strategy and the sourcing rule has been selected as Pull. This combination then reveals to user inputs940,942,944,946, and948for setting Node Calculation940and942and Quantity Calculation944and946. This section of the input refers to rules and policies that the requisition manager will follow as it evaluates the pipeline and releases runtime requests for replenishment. If a alternative Supply Strategy938and/or Sourcing Rule had been select, the node calculation and quantity calculation input options revealed may have been different.

Similarly, the example quantity calculation944is set to Use threshold and quantity, which further revealed input options On-shelf threshold946and Requisition Quantity948. If an alternative Quantity Calculation944had been selected, other input options may have been revealed. Supply Rules950,952,954, and956further set replenishment policies for the pipeline. Fulfill rule950identifies how the supplies may be grouped for shipment, such as one shipment or many shipments, for example. Supply group type952and supply group954specifically identifies the number of supplies that are evaluated with this pipeline definition. Lot size956allows implementation of a minimum order rule which will adjust the result of Quantity Calculation944.

With reference now toFIG. 10, a flowchart illustrating a process for modeling supply chain networks is depicted in accordance with an advantageous embodiment. The process inFIG. 10may be implemented by a component such as analysis system404inFIG. 4, for example.

The process begins by initializing a model using a model manager (operation1002). The process generates a core database using the model manager (operation1004). Generating the core database may include, for example, importing a text file from a storage device of the system, such as storage432inFIG. 4. The process generates a number of nodes within the model using a number of code objects (operation1006). The number of code objects are fully compiled, self-contained, blocks of code having a number of auto-build macros, such as number of code objects408inFIG. 4, for example. Generating the number of nodes may further include locating and obtaining global data structure information and a description of a local node data structure from the core database to build a local node data structure, for example. A node database referencing the node descriptions stored in the core database may be generated for each of the number of nodes generated within the model during this process. A messaging system may be provided between the number of code objects within the model to communicate ordering and replenishment events using a token architecture, for example.

The process generates a number of pipeline data objects configured to describe supply chain relationships between the number of nodes within the model (operation1008). The number of pipeline data objects each specify individual supply chain relationships between nodes. A set of pipeline data objects may describe a complete supply chain network, for example. The process runs a simulation using the model to analyze the supply chain relationships (operation1010), with the process terminating thereafter.

During a simulation, the model may generate a request for supplies using a requisition manager and receive the supplies according to the request for the supplies using a supply control manager, for example. In another example, the model may receive a request for supplies using the requisitions manager and send the supplies according to the request using a supply control manager.

The flowcharts and block diagrams in the different depicted embodiments illustrate the architecture, functionality, and operation of some possible implementations of apparatus, methods and computer program products. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of computer usable or readable program code, which comprises one or more executable instructions for implementing the specified function or functions. In some alternative implementations, the function or functions noted in the block may occur out of the order noted in the figures. For example, in some cases, two blocks shown in succession may be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

The different advantageous embodiments recognize and take into account a number of different considerations. For example, the different advantageous embodiments recognize and take into account that current tools for modeling supply chain performance generally are purchased from a vendor, operate at less level of detail than desired, and typically focus on inventory stocking level optimization. Some current tools use a multi-step, iterative, marginal analysis procedure to determine optimum stocking levels. Other current tools use risk-based algorithms and forecasting to determine optimum stocking levels. Still other current tools use mixed-integer/linear programming combined with a proprietary discrete-event simulation engine to determine optimum stocking levels.

The different advantageous embodiments further recognize and take into account that current tools use analytical methods to solve inventory optimization problems and provide guidance as to recommended inventory levels. These current tools have a high product cost, are complex and time-intensive to set up and execute, and have limited or non-existing capabilities to model non-supply chain specific aspects of a total system architecture.

The different advantageous embodiments further recognize and take into account that current supply chain modeling tools are expensive and complex to set up and run, and lack the capability to easily expand the scope of the model to model lower level details about a system design. These limitations create burdens for concept analysts, system engineers, and logistics analysts, who may need to construct a model to analyze and predict supply chain performance, while also addressing aspects of the system impacted by the supply chain, such as maintenance requirements, resource requirements, manufacturing requirements, transportation system design requirements, and the like.

Thus, the different advantageous embodiments provide a system that offers program analysts, systems engineers, and logistics/supply chain experts the ability to rapidly develop accurate, efficient, high fidelity simulations of supply chain and logistics networks. The different advantageous embodiments provide a reusable supply chain modeling capability to support inventory management assessment, performance-based logistics contracts risk assessment, and manufacturing schedule risk assessment. This system meets a need within a company for a supply chain and logistics modeling capability that can be applied across multiple programs, provides detailed output at the individual parts level, and can interface to other company logistics and performance analysis tools. The different advantageous embodiments provide a system that reduces the time and costs required to develop supply chain network simulations, makes it easier to model overall system operational availability as a function of supply chain performance, and provides a modeling architecture that can easily be expanded to add additional fidelity as needed at minimal cost.