SAP MII, HANA/ESP and Lumira (Technical)
It's great to see the growing interest in the way visibility from the top-floor (enterprise) can be extended to the shop-floor (operations) levels in an automated and secure fashion. The growing maturity of end-user tools, like Lumira, for data analytics on Big Datasets contained within HANA is a fantastic way to gain insights in your business operations. As you already know the Lumira tool can retrieve data from the HANA environment but did you know that Lumira can also retrieve data directly from the MII Query Templates?
For a higher-level view of how to leverage manufacturing operations data inside of the Lumira product see my business level BLOG here: SAP MII, HANA/ESP, and Lumira (Business). For a step by step walk-through of how to access and re-use your MII Content from inside of Lumira go here: SAP Lumira and MII (How to)
The following document will outline the various features and the deployment options that are now available as part of the SAP MII 15.0 release and will even highlight some options available with previous releases.
The above scenario is common practice to see these days and more and more customers are demanding access to central and remote data simultaneously. There are a couple of scenarios as outlined in the aforementioned link that require coverage, but to focus on the technology and software capabilities let's focus on what deployment options are now possible with the SAP MII solution. The positioning with the SAP enterprise story around SAP MII and HANA:
- MII 15.0 on NetWeaver (AS Java) using HANA as the DB
- MDO, KPI & PIC all utilize the HANA DB
- MII 15.0 with predefined OEE content & data-model also has predefined SLT replicators to load HANA DB (default 15min)
- MII 15.0 on NetWeaver (AS Java) in the HANA Enterprise Cloud (HEC)
- By the time that you read this the term Cloud has probably already been replaced by a new term: Software Defined Networking (SDN) http://en.wikipedia.org/wiki/Software-defined_networking
- MII 12.1 and newer pushing data to HANA Tables
- JDBC direct via HANA JDBC Driver
- HTTP(S) via DSXI services on HANA
- PCo 2.3 streaming data to SAP ESP and ESP pushing into HANA (SAP MII & ESP Integration)
- Manages data in-flight to create snapshots of important datasets
- PCo 15.0 streaming data to HANA Tables
- Manages snapshots of machine/automation data
- Lumira native interface to MII to synchronously retrieve data from MII 14.0 and newer Query Templates
- HANA Smart Data Access (SDA) interface to synchronously retrieve data from MII 15.0 Query Templates
All of these architectural options provide new and interesting industrial use cases but leverage the same core set of technologies to achieve them.
For those of you familiar with the SAP MII product already you already know that it's not so much a one deployment option fits all product. Rather it will scale up and down depending on the maturity of your implementation and the use-cases you are trying to address. Some deployment options are better suited for various industry specific use-cases and these overlap with maturity of the deployment as well...what is meant by this is that it is common to see architectures for different reasons. There are of course pros and cons to both approaches and I do outline these here: SAP Manufacturing Implementation Architecture around limited survivability and latency of reporting built into the network but these may not matter for the specific scenario that is attempting to be addressed. This is also covered in this document here when positioning with other SAP products, like SAP PI: SAP MII and SAP PI in the Industrial Space
A centrally deployed MII environment (Note: MII 15.0 supports the HEC environment) is common to see for the handling the following scenarios:
- Maturity - New customer looking to pilot the software, central data centers are quick and cheap to setup SAP instances and require low overhead to kick off a project and prove out value. Please note that as the deployment matures there is a gravity that the plants/operations centers generate that pull MII closer. See the On-Premise Deployments section for more details.
- Maturity - Customer has multiple deployments of MII across various locations and wants to leverage the ability of a central MII instance to security communicate with other instances of MII for reporting across the various locations
- Industry Use Case - Centralized deployments are very successful where disconnected operations is not critical and where speed is less important (ie: Bldg Mgmt or Manual Data Collection). This is also true for various industries (ie: Utilities or Upstream Oil & Gas) there is no real need for an on-premise deployment as the assets they are interacting with are not concentrated in a plant location but rather across various locations. These assets still interact with the same DCS/SCADA/Historian systems as the plant automation systems do, so the standard MII/PCo products are still used to collect & contextualize the data.
- For Upstream Oil & Gas it is important to point out that we do provide an Upstream Operations Management (UOM) application that leverages SAP MII/PCo in this same architecture; details are here: Upstream Operations Management (UOM) - Upstream Oil & Gas
This is the most common deployment option and a locally deployed (or on-premise model) SAP MII is also very common to see in more mature customer implementations and provides the most benefit for the organization. There is a gravity that starts to form that typically pulls MII instances towards the more mature plants as a local server provides a lot of various capabilities that are often required by the local plant employees that require a low-latency and highly-availability environment. These two requirements almost always lead to an on-premise deployment of SAP MII and this provides a nice and easy way to scale out a deployment to accommodate many scenarios. You can still of course keep the central instance (Note: MII 15.0 supports the HEC environment) of MII for lower volume or smaller scale plant support and also for the larger locations with more mature requirements you can also move an MII server instance to the local site. This gives a secure footprint at the local site and also provides local visibility to the local systems along with store and forward capabilities and synchronous remote access between the central and local servers via the Virtual Data server interface for secure and lightweight MII Peer-to-Peer communication.
As a reference here are various architectural deployment diagrams that you can use to outline the how and why each deployment option makes sense to you and your business and they help to reinforce the above points around deployment options and the types of users interacting with the various MII application(s) you have: