1. Integration

In contrast to traditional simulation modeling tools, Simio is designed from the ground up to become the process Digital Twin with a focus on data integration to existing ERP/SCP/MES/IOT and any other data sources.  This requirement has driven the design of both the data and modeling features of Simio.

Simio connects to both master data (static) such as materials, bill-of-materials, routings, work centers, staffing levels, etc., as well to the transactional data (dynamic) that such as work orders, work-in-process the status of resources and inventory of both raw and finished materials.  The relationship of Simio RPS to the Enterprise systems is illustrated in an example in Figure 1 below.

Figure 1: Simio as Process Digital Twin connected to the Enterprise Systems

Although the transactional data may come from many different sources, most of the critical data comes from the ERP, SCP & MES systems.  These systems provide the primary data sources for managing production.  It provides a master list of production orders – such as release dates, due dates, and order quantities – along with component products and end products required to meet customer demand.  This list also has associated secondary data such as job routings, bill of materials, etc.  It also provides a material purchasing schedule that list items required from outside suppliers, including their expected arrival time, with the goal of matching these materials up to the production schedule.

In some cases, some of the transactional data may reside outside of the ERP, SCP & MES systems in spreadsheets, databases, flat files, or other forms.  Simio is designed to import transactional data from all these varied sources.

Simio provides three (3) key features for integrating the scheduling model to transactional and operational data.  The first is an in-memory relational database that is fully configurable to match the schema of any external data source.  The second is an open architecture for configurating data connectors for importing transactional or operational data from external sources.  The third is modeling constructs that are fully configurable to map to in-memory relational data in the data tables.

These features combine to provide a modeling framework that can map to any external data, regardless of the source or data schema.  Simio’s in-memory configurable relational database provides the key interface between the enterprise data and the model logic.  The transactional and operational data is imported into this database and held in memory for fast execution of the digital twin model.  The model logic can both read from and write to this in memory database.

The database schema is fully configurable and can exactly match the existing schema of the external data sources, often eliminating the need to transform the data during import/export.  The import/export action is done through Simio Data Connectors.   Standard data connectors are provided for most popular databases, Excel, and CSV files as well as Web APIs.

Simio provides interoperability between systems as summarized and shows in Figure 2 below:

• Excel and CSV connectors (Excel)
• Database connectors (SQL/Oracle, etc.)
• AVEVA, Tulip MES (or others) using the standard APIs or Web services
• IoT devices, External Solvers, and AI tools using PTC Kepware, HighByte, etc.
• Web API or Database (Cloud Integration) (SAP S4 HANA, Oracle, Kinaxis, Microsoft Dynamics, OMP, etc.)

Figure 2: Simio Integration Capabilities and Data Connectors

The transactional data for the digital twin model is typically Imported or downloaded from the ERP at the beginning of each planning period and is static during the planning period.  In contrast the MES operational data is constantly changing and therefore the MES data connector is often a dynamic connector.  For example, a machine failure detected by the MES may automatically trigger Simio to generate a new schedule that is based on the expected downtime for the machine.  The Simio integration framework supports both static and dynamic data connectors for both transactional and operational data.

As the enterprise data landscape evolves and customers develop central data warehouses, typically in the cloud, using techniques such as Unified Name Space (UNS) to map and transform data to be ready and usable by most applications such as analytics tools but also support the creation of a digital twin such as Simio which is fully gata generated and driven from both static and dynamic data of the factory/supply chain/warehouse. Figure 3 below shows is more progressive or modern approach to better support digital twins and achieving objectives such as low-touch/no-touch or even a full smart factory or system.

Figure 3: Simio Integration to a Central UNS Cloud Storage

To support most integrations into the ERP, SCP and MES systems Simio created two primary methodologies for implementation based on the existing customer IT infrastructure and customer preference.  This support is for both an Indirect (“Push”) and a Direct (“Pull”) approach to the integration based on the customer’s requirements.

1.1 Direct Integration (“Pull”) Approach

In this approach Simio will trigger a pull from the relevant data systems based on a timed event or user input such as using the SAP API Business HUB using the Simio Web API Data Connector. This ensures Simio is using the most up to date information. The direct integration approach is shown in Figure 4 below:

Figure 4: Illustration of the Direct Integration (“Pull”) Approach

The Direct integration (“Pull”) approach is described at a high-level below:

1. Simio initiates the integration workflow by sending a GET request to a middleware application associated with an ERP, MES, SCP, or IoT system.
2. Upon receiving the initiated call from Simio, the middleware application acts as a web messenger, forwarding the request to the ERP/MES/SCP/IoT system, which then generates the necessary data and sends it back to the middleware application.
3. The middleware application sends the message to Simio formatted in JSON or XML, which is stored in Simio’s memory-resident relational database using an XSLT (v1.0) stylesheet for data mapping and translation.
4. Upon completion of the simulation run, Simio leverages full bi-directional integration capabilities, allowing it to push (POST) the scheduling information back to the middleware application and subsequently to the source ERP/MES/SCP/IoT system.

1.2 Indirect Integration (“Push”) Approach

Using an additional persistence data layer Simio also created a “Push” approach for integration to existing ERP, SCP and MES systems as illustrated in Figure 5 below. Updates are pushed from the ERP, SCP and MES systems via middleware to the staging database (persistence layer) driving Simio such as using the SAP Production Optimization Interface (POI). Data is then ready when users want to create a schedule and works well for routine daily or weekly scheduling. The updates must be synchronized to ensure Simio doesn’t trigger the next planning or experimentation session until the update has been completed.

Figure 5: Illustration of the Indirect Integration (“Push”) Approach

The Indirect integration (“Push”) approach is described at a high-level below:

1. Initiated by a job scheduling process or trigger, the ERP/MES/SCP/IoT system generates messages that are sent to a middleware application.
2. Before forwarding messages to Simio, the middleware application may need to perform transformation mapping based on the intended use of the data to align with Simio’s model table requirements. The updated messages are then transferred to the staging database utilizing the middleware database adapters or XML files.
3. Simio then pulls the table data from the database using a data connector, updating the Simio in-memory tables.
4. Upon completion of the simulation run, Simio leverages full bi-directional integration capabilities, allowing it to push scheduling information back to the staging area for access by the middleware application and subsequently the source ERP/MES/SCP/IoT system.

2. Systems Architecture

The systems architecture is different in most deployments based on the customer’s IT landscape. Based on the experimentation, planning and scheduling requirements and workflows the source systems will be identified as part of the integration and workflow identification process. Figure 6 below provides an illustrative example of what the systems landscape can contain and how the different systems will interact in a typical enterprise deployment.

Figure 6: Example Enterprise Deployment Systems Architecture

3. Simio RPS Deployment Options

Simio RPS offers several deployment options to support various operating environments and work methods.  Since Simio RPS is both a simulation and scheduling solution, it is used by different people in different user roles as the project progresses from its design phase (simulation and analysis) to the operate phase (planning and scheduling). Based on the requirements a customer can deploy Simio RPS in any or all of the deployment options listed and shown in Figure 7 below.

3.1 Option 1 – Desktop

3.1.1 Design and Operate

During the model development and analysis phase it is often preferred to deploy Simio RPS on a laptop or desktop.  This supports offline work by project team members as models are stored as compressed XML files that are easy to transfer between computers and even email to team members whenever updates have been made to the model for review and testing.  The team members will often be working off-site for most of the project best utilizing this option.  This option is also valid for operational deployment of the scheduling system provided the desktop or laptop has access to the customer’s network to access the operational data required to run the model for experimentation or to generate a production schedule.  This option works particularly well during the early deployment and testing phase of the solution while ongoing enhancements and model changes are required by various team members to fine-tune the model logic.

3.1.2 Operate

Simio can be configured to provide an operational view.  Using this operational view, the Simio model is used for creating schedules and running different experiments to test operational strategies by changing preset data and properties included during the model development phase. The user cannot make any model changes using this deployment option.

3.2 Option 2 – Cloud Solution (Public (Azure) or Private (On-premises))

The cloud-based solution of Simio, the Simio Portal Edition, has 2 deployment options.   Its public option is hosted on the Microsoft Azure service.  Simio’s private option is installed on a Windows Server with IIS (Internet Information Services).

To host the Simio on-premises portal, the customer will be required to lease or procure the required hardware infrastructure to create this hosted environment behind their own security systems (firewall). The hosted option can also be used for experimentation to evaluate operational strategies by changing set data and parameters as included during the model development phase.

Figure 7: Simio Operational Deployment Options

4. Software Requirements for Desktop/VM Server

1. Windows 8.1 or later, or Windows 10 Anniversary Update or later.
2. Both 32- and 64-bit operating systems are fully supported.
3. If installing on Windows 8.1, the April 2014 update (KB2919355) must be installed first (see https://support.microsoft.com/en-us/kb/2919355). Update 2919442 is also required (see https:// support.microsoft.com/en-us/kb/2919442).
4. Simio requires .NET Framework Version 4.7.2, which is part of the default installation.

5. Recommended Hardware Requirements for On-Premises Portal Deployment

Windows Server Configuration

1. Computer with quad core processor with 2.6 GHz or faster clock speed. Additional cores recommended for optimal performance.
2. 64 GB or more of RAM recommended, 16 GB of RAM minimum.
3. 1-Terabyte Disk (solid state preferred) with RAID support for data. The amount of disk space necessary depends on the size of the model, number of job steps being scheduled, number scenarios being saved, and the amount of data kept online in the production database.
4. Microsoft Windows Server 2012 R2 or higher
5. Microsoft SQL Server 2012 or higher.
6. IIS with ASP.NET 4.7 support.

NOTE: The use of 3 separate servers for database, application server and IIS can be configured, but is not required.

6. Additional Reference Materials

Below are additional references providing more detailed information regarding the specific integration requirements for different enterprise systems.

SAP Business Technology Platform

https://github.com/SimioLLC/SAPCloudPlatformIntegration

AVEVA MES

https://github.com/SimioLLC/AVEVAMES