1 Introduction

The objective of production planning (PP) is to decide on product types and quantities to produce during specific future periods to meet demand. PP is typically decomposed into decisions at different levels in the organization [1]. Bitran and Tirupati [2] identified the PP levels as enterprise, operational, and process levels. Enterprise level planning relies on aggregated estimates while lower level planning uses up-to-date, granulated data. Figure 1 illustrates the conceptual view of inputs and outputs for different PP levels. The input data for enterprise planning are customer and forecasted demands, projected capacity, and inventory. The outputs are the details of production release and sales, also called the master production schedule (MPS). Lower level plan outputs are scheduling policy, work in progress levels, cycle times, and dispatching.

The aggregate PP problem can be formulated as a linear mathematical model to determine future production levels, capacity, labor force, and inventory [3]. The enterprise resource planning (ERP) tool determines production resources, financial, and delivery of raw materials to execute the plan. The manufacturing execution system (MES) uses the MPS to provide shop floor production instructions. The outputs of the MES including dispatching rules and procedures are often evaluated by simulation taking into account real-time events such as machine breakdowns and part shortages [1]. This typically results in a more detailed and up-to-date situation analysis.

Clearly, the degree of coordination between enterprise-level PP, lower-level PP, and the integrated simulation models plays an important role in the success of PP. In particular, the prediction of shop floor events and anticipated capacity being fed back to enterprise-level level to update the MPS [4]. PP methods such as CONWIP cannot succeed without feedback of shop floor simulation results to enterprise level planning [5, 6]. Moon and Phatak [7] also showed that bi-directional feedback between a stochastic shop floor simulation and ERP improved lead-time accuracy. Kulvatunyou and Wysk [8] demonstrated with a simulation model that decomposition and modular integration of resources, process, and production data led to up-to-date analysis. For these reasons, we propose that simulation-based integrated PP enabling a cyber-physical system approach of combining computational and physical elements to adapt to changing environments be employed. However, there are problems to achieving such integration. This paper provides a background to addressing those problems by reviewing existing methods, PP interface standards, and a sample integration architecture. An extension of the SIMA reference architecture [9] is proposed to define inputs and outputs to activities, and information needs at each PP level.

The rest of the paper is organized as follows. Section two describes the causes of PP and simulation integration problems. Section three discusses a reference architecture that can be adapted for the simulation-based integrated PP to increase accuracy. Section four concludes the paper and discusses future work.

Fig. 1.
figure 1

The input and output data between different PP levels.

Full size image

2 Analyzing Problem Sources

We describe the PP and simulation integration problems by examining characteristics and the challenges with applying existing standards to the problem.

Temporal Characteristics of the Problem.

The decomposition of the PP problem into enterprise, operational, and process levels is consistent with the ISA-95 CIM (Computer Integrated Manufacturing) standard model. ISA-95 activities are classified into 4 levels, shown in Fig. 2. Levels 1 and 2 activities manage manufacturing processes. At level 1, processes are controlled and data is gathered in almost real time (1 ~ 20 ms). The time-scales at level 2 are hours, minutes, and seconds. At level 3, workflows are managed in days, shifts, hours, and minutes. Level 3 activities interface with the shop floor equipment and machines [10]. The MES plays a role mostly at this level. At level 4, enterprise planning, carried out by ERP, has time-scales of months and weeks [11]. These differences in activity time-scales imply different objectives and plans for each level.

Planning and Operation Gap.

Level 4 plans are supposed to be realized in levels 2 and 3. However, data aggregations at higher levels and unexpected events such as order change and machine breakdowns result in operational level outputs that differ from original high level plans.

Fig. 2.
figure 2

ISA-95’s hierarchy model and associated systems and functions.

Full size image

System Interface Difficulty.

Standards are essential for manufacturing data management and to integrate multiple systems. Figure 3 shows examples of standards and systems. Data is collected at levels 1 and 2. The 4th column of Fig. 2 lists the functions provided in the systems. ERP for enterprise planning and MES for lower level PP do not interface well especially if provided by different vendors. Because of this, the often-required adjustments to production plans may be difficult to carry out.

Data for Simulation.

Aggregate PP focuses on maximizing on-time demand satisfaction and minimizing inventory while detailed PP at lower levels focus more on minimizing cycle times, resource utilization, and maximizing bottleneck utilization [1]. As such, simulation objectives are different for each level. The corresponding differences in details, scope, and data complicate the coordination of inputs and outputs with the multi-level simulation models. This problem can be broken down into two aspects: data interoperability and data collection.

An impediment to wide simulation usage is that simulation tools have a very low level of data interoperability among themselves and with other manufacturing applications [12]. Recognizing this problem, the Simulation Interoperability Standards Organization (SISO), in collaboration with NIST, developed the Core Manufacturing Simulation Data (CMSD) [13]. CMSD can facilitate exchanging data across different simulation tools used in the supply chain. But it does not support integrating simulations along a vertical scale, i.e., across hierarchical levels. Its usefulness for multi-level PP simulation is, therefore, limited.

Figure 3 shows other exemplar standards against the PP level. The OAGIS standard, from the Open Applications Group, establishes integration scenarios for a set of applications including ERP, MES, and Capacity analysis [14]. OAGIS defines business messages that allow application-to-application and business-to-business integration. As such, the main emphasis for OAGIS is at the enterprise level while the ISA-95 is more emphasized at the operations levels. Therefore, there are gaps in these standards for modeling the exchange of data between the different PP systems, and between PP and simulation tools.

Fig. 3.
figure 3

Systems and data standards for simulation data integration.

Full size image

The activity that precedes data processing and modeling for simulation is data collection. Jung [15] categorized data collection methods into automated, semi-automated, and manual methods. For automated data gathering, communication interfaces based on standard protocols have been developed. MTConnect [16, 17] has recently emerged as a standard for automated, real-time data gathering from equipment. The current scope is limited to machine tools. An enhancement to cover other kinds of equipment is necessary.

OLE for Process Control - Unified Architecture (OPC-UA) (IEC62541) [18] is a communication protocol for interoperability from the OPC Foundation. MTConnect and OPC-UA support interfaces to levels 1 and 2 (Fig. 3). MTConnect and OPC-UA have collaborated to produce a companion specification called MTConnect-OPC UA to ensure interoperability and consistency [19]. Other OPC UA companion specifications exist that may support data collection from other kinds of equipment.

In order to model interdependencies between PP functions and simulation objectives, a references model is needed. A reference model is an abstract framework consisting of an interlinked set of clearly defined concepts for unambiguous communication [20]. In the next section, we use the System Integration for Manufacturing Applications (SIMA) Reference Architecture to describe entities and relationships involved in the multi-level PP. We propose to extend this model to develop a unified PP function that is enabled by a multi-level simulation.

3 Integrated Production Planning Based on Simulation

This section describes the proposed feedback control mechanism and an introduction to the SIMA reference architecture and proposed enhancements.

Fig. 4.
figure 4

Feedback mechanism for simulation-based integrated production planning

Full size image

Feedback Control Mechanism Based on Simulation.

The hierarchical decision system relies on a top-to-down approach where decisions at each level being passed down to the level below for execution. The feedback from a lower level to a higher level is used to modify the higher decisions so as to enable feasibility at the lower level. While research in feedback mechanisms including use of simulation has been reported, it has mainly been limited to two levels [21]. Secondly, the results have not included practical implications of implementation by use of standards and protocols. In the proposed simulation enhanced feedback, each level within the PP hierarchy has two feedback inputs, as shown in Fig. 4. First, the outer loop, which represents the traditional method of feedback where upper plans are revised to enable feasibility at lower level. Second, the inner loop that providers the output of simulation as a consideration for PP revision. We assume that lower levels have models that can better process more detailed information. From the shop floor, for example, data is used along with simulation to predict events as well as capacity and project inventory levels. This information along with the schedules passed from the scheduler is used to determine work dispatch procedures to ensure optimized production. These new procedures have to be aligned with schedules. The same procedure is used when revising the production plan at the enterprise level. The simulation models need not be integrated or run concurrently, but during usual events that necessitate production plans revision. In the next subsection, we introduce and discuss the SIMA reference architecture with which the feedback control mechanism can be integrated.

SIMA Reference Architecture.

The System Integration for Manufacturing Applications (SIMA) Reference Architecture focuses on standards and technologies to integrate manufacturing software applications in design, fabrication, and assembly of discrete manufactured parts. It was developed at NIST using IDEF0 diagrams [22]. In IDEF0, the activities, shown as boxes, represent functions and operations. The fundamental objects of an IDEF0 model are activities, information flows and resources that include controls and mechanisms. Inputs are arrows into the left side of the activity box. Outputs are arrows exiting the right side of the activity box. Controls are arrows into the top of the activity box, while from the bottom, are the mechanisms or means by which activities are performed. A set of activities, information flows and resources are defined in multi-level activity models that describe the engineering and operational aspects of manufacturing a product from conception through production. The activity model provides a frame of reference for identification and standardization of interfaces between activities through information flows [9].

Within SIMA, the activity model for developing the production plan and coordinating product orders with shop floor activities is the “Develop Production Plan” activity model shown in Fig. 5. Designated as A41 in the reference architecture, this activity model is relevant to developing the integrated PP system. It has four sub-activities, briefed as follows. A411 “Create Master Schedule” determines product quantities to be produced during a future planning period, given customer orders or forecasts. Customer orders are defined by product type, quantities, and due dates. Considering anticipated capacity and capacity restrictions, this sub-activity develops the MPS. This activity takes place at Level 4 in the ISA-95 Control Level. The OAGIS standard can support this sub-activity. A412 “Define Capacity Requirements” determines the long term capacity requirements based on the MPS, capacity projections and possible adjustments. A413 “Create Production Orders” generates production orders in quantities determined by the MPS and resource requirements. These two sub-activities correspond to Level 3 in the ISA-95 standard. The MES and CMSD standards are applicable. Lastly, A414 “Monitor Production Orders” monitors the status of production orders from the shop floor. Thus, it requires information to be collected from Levels 2 and 1 and fed into Level 3 for aggregation. Level 2 and 1 information may be supported by the MTConnect and OPC-UA communication protocols. In the IDEF0 diagram, activities are interconnected with information flows. This connectivity between activities across control levels identifies the integrated PP requirements.

The proposal is to make the feedback mechanism defined in Fig. 4 as part of the SIMA architecture. The additions are the validation activities to be performed using simulation. Therefore, interfaces need to be defined to integrate simulations, manufacturing applications, and databases. Extensions to the existing CMSD specification will be investigated to support such vertical integration.

Fig. 5.
figure 5

SIMA manufacturing activity model: A41 develop production plan.

Full size image

Driven by simulation validation objectives at each level, the new proposed activities can be defined as follows:

  • Simulate production plan

    • Inputs: current work-in-progress and inventory, master production schedule, cycle time, takt time, required inventory levels, expected capacity variation,

    • Outputs: production levels, sales, finished products inventory, backlogs, fulfilment rate

    • Control: strategic policy to control demand, inventory, capacity, variability, demand satisfaction

    • Mechanism: production plan simulation model

  • Simulate schedule

    • Inputs: production order sequence or schedule, lead times, due dates,

    • Outputs: production order release, production order completion, work in progress levels, number of orders filled, number of orders missed

    • Control: resource (people and machine) levels, batch size, target performance levels such as resource capacity utilization levels, work-in-progress level, and safety stock

    • Mechanism: scheduling simulation model

  • Simulate dispatch rules and procedures

    • Inputs: job sequence,

    • Outputs: resource utilization, throughput rate, actual cycle time,

    • Control: dispatching rules, resource production rates, target utilization level, upper and lower stock limits,

    • Mechanism: real-time control simulation model.

4 Conclusion and Future Work

This paper has pointed out the need for increased concurrency among production planning at different hierarchical levels in a manufacturing organization. This paper first described the PP planning function at different hierarchical levels followed by an overview of PP integration challenges. Simulation based prediction of shop floor events, inventory levels, and capacity by using real-time events can reduce the potential infeasibility and accuracy of the multi-level PP process. However, these simulations also need to be integrated with production management systems. To that end, exemplar standards and their limitations to integrating simulations and production management systems have been discussed; and a framework based on the SIMA reference activity model to extend those standards have been proposed.

While automated tools with tasks from data collection, analytics, and scheduling have been developed, employing a cyber-physical approach that integrates these methods and standards at different levels with simulation assisted human decision making will result in a more accurately responsive PP system. Future work will include the description of data requirements for inputs and outputs at multiple levels. Within the SIMA architecture, the additional activities, i.e., simulate to validate production plan, simulation to validate schedule, and simulate to validate dispatch and production control procedures will be validated against the specific needs and environments of individual manufacturing organizations.

Disclaimer.

This effort has been sponsored in part under the cooperative agreement No. 70NANB13H153 between NIST and Morgan State University. The work described was funded by the United States Government and is not subject to copyright.