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:
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.
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:
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:
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
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.
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.
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.
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
Windows Server Configuration
NOTE: The use of 3 separate servers for database, application server and IIS can be configured, but is not required.
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