Searching for the "Operational Analytics on Steroid" Formula - SAP MII

on HANA
Posted by Dipankar Saha in SAP Manufacturing Integration and Intelligence (SAP MII) on Jun 30, 2015 5:32:27 PM
inShare2

SAP MII has come a long way since its inception as Lighthammer and then erstwhile acquisition by SAP and re-branded as SAP MII, which
paved the path to manufacturing intelligence as a new domain of operational analytics. With time as the product got matured enough to
foraying into the integration aspects of manufacturing automation and execution systems with ERP and thereby positioning itself as the
middleware solution for "business to manufacturing" system integration.
Having the matured analytics platform now available on MII which can do trend analysis, multi-dimensional analysis and KPI modeling on near
real-time data, along with the self-service composition environment (SSCE), the next expectation comes in to handle huge volume of timeseries and tabular data collected from operations at the manufacturing plants, to do long-term trend and regression analysis on it. Moreover,
manufacturers now want to predict and prevent operational issues such as machine downtimes, material quality and performance bottlenecks
in production lines.
SAP MII in its traditional architecture on SAP NetWeaver Java and standard databases, may not be the ideal platform to do such analytics using
huge data set, as it uses a standard database used by NetWeaver WebAS to store and manage the data. With SAP MII 15.0 now it is possible to
install SAP MII on NetWeaver 7.4 which can use HANA as the database, thereby opening gateway for MII to leverage the power of HANA as an
in-memory platform. But the question is - whether MII as a solution is now mature and capable enough to leverage the power of HANA? Let us
explore and try to find an answer to this burning question.
The power of HANA lies in couple of major aspects - columnar and in-memory storage of data and ability to embed complex data processing
and calculations in data layer as calculation views. You can create tables in HANA as columnar tables and then define the attribute views (fact
tables), analytic views (measure and dimenions) and calculation views (complex calculations and data processing), which can be accessed
from the user interfaces or business logic layer as OData services or by JDBC.
Let us now explore different options and use cases for MII on HANA to understand how MII can leverage the power of HANA and provide the
"operational analytics on steroid" formula.
Data Persistency
MII uses Manufacturing Data Objects (MDO) which is a framework in MII to model custom data model as per the application requirements. It
creates database tables in the underlying database which NetWeaver uses. When MII is installed on HANA, the MDO are created as column
tables on HANA database as I understand. But there is a caveat - the database tables and its columns created from MDO do not use the same
name of the MDO provided by the user, instead it uses some cryptic names e.g. MDO100, FIELD100, etc, which is mapped to the user-defined
MDO names in an internal application database table. So it is difficult to identify the table created for a MDO from the database layer. I
understand from SAP MII product development team that this issue will be addressed in future release of MII to have the MDOs created in the
database with the same user-defined names as in the MII catalog.
So having columnar tables and in-memory storage with fairly massive database capacity of HANA, large amount of data can be stored on the
MDO and KPI, which is not otherwise recommended when MII is installed on traditional database. But if MDO is used, database operations or
additional objects (such as HANA views) cannot be easily created at the database layer as MDO tables have cryptic names which makes it
difficult to identify.

The workaround may be creating the tables in HANA database itself instead of using MDO. From SPS09 of SAP HANA there is support for
storing time-series data as well, which is useful to store data from Historian or SCADA queried by MII/PCo.
Reporting & Analytics
Usually for analytics and reporting on MII, MDO, KPI or SQL queries are used to query the data from MDO, KPI or custom database tables (when
external databases are used). The queries are created and managed on MII which are executed from Business Logic Transactions or web pages
in MII. When HANA is used, it is not recommended to create queries directly on the column tables, rather create attribute, analytic and
calculation views on the tables at the HANA database layer, on which the queries can be used or those can be executed directly as ODATA
services from the consumer layer. As explained above, while using MDO it is not possible to create those views from HANA database layer as it
is difficult to identify the correct MDO from there due to the cryptic names. So directly MDO queries can be developed on MII, which may not
get the maximum performance benefits which HANA provides. Otherwise the tables need to be created in HANA database layer itself, instead
of using MDO, and on which the HANA views can be developed. This way it may get the maximum performance benefit from HANA, but shall
bypass the content management and other features of MII. Also it may require sometime to use some other data such as plant hierarchy
(stored in Plant Information Catalog) or other configuration data available in MII for the analytics and queries.
One possible approach is developing the tables and views in HANA database layer, which can be accessed from MII SQL query interface
by JDBC connection, on which the SQL queries can be developed on MII. BLS transactions can be then developed on MII to incorporate the
business logic which will consume the queries and develop the end to end application logic. User interfaces then can be developed using
SAPUI5 on MII consuming the BLS transactions as Xacute queries.
The architecture overview of the same is explained in the diagram below:

KPI Analysis
MII provides KPI framework using which multi-dimensional KPI objects can be defined to persist measures with the different dimensions (e.g.
Time, Plant, Material, Workcenter, etc.). With MII on HANA, KPI objects are also created a column tables in HANA. The KPI objects are anyway

created in the HANA database layer as multi-dimensional cubes on which KPI queries can be developed on MII to query the data based on
different aggregation and time-periods with one or more dimensions. Having MII on HANA it makes it much easier to store long-term and huge
volume of data in KPI objects and create analytics on it.
Plant Hierarchy Management
SAP MII provides a framework called Plant Information Catalog (PIC) to manage hierarchy of assets and objects in manufacturing plants and
map the individual objects to tags which are the sensor data points maintained in Plant Data Historian or SCADA/DCS. The plant hierarchy with
different tags (each object can have multiple data points or tags) can be quite complex and huge. Querying the hierarchy in real-time is
usually performance intensive, if the structure is complex and have huge number of nodes. As PIC objects leverages HANA persistency
mechanism on MII on HANA, working with PIC is supposed to be much easier in terms of performance.
PCo Notification Processing
SAP Plant Connectivity (PCo) provides an external adapter with SAP MII to send notification messages on change of tag values or files in an
external system such as Plant Historian, SCADA or a remote folder. This is useful to trigger certain business logic in MII when the value of one
or more data points changes to a certain extent e.g. machine input power tag value in SCADA becomes zero signifying a machine shut-down
which may need a plant maintenance notification to be created in SAP ERP via SAP MII. In a large plant with many machines and mostly
automated production lines with multiple data points, the number of notifications generated from SAP PCo and sent to MII can be quite huge.
Based on the notifications sent from PCo, custom logic in MII can decide an event (e.g. machine breakdown) or a trend. When MII running on
HANA, this can be another scenario which can leverage the performance boost provided by HANA in-memory processing. Moreover, additional
features such as complex event processing and predictive algorithm can be developed on HANA using the Predictive Analysis Library (PAL) to
provide more insight and intelligence on the data from notification messages.
Streaming Analysis by Smart Data Access
In SAP MII 15.0 SP03 and above, a new connection type is available for Smart Data Access (SDA), using which a HANA system can access and
query the MII data as virtual tables dynamically. Through the SDA connector all PCo and Xacute queries are exposed (Xacute queries are BLS
transaction queries which can embed any logic or any other queries) to the HANA system, on which real-time queries can be performed from
HANA. So it provides a feature enable real-time monitoring or streaming data processing (by synchronous queries) for events or predictive
analysis. One good example of streaming data processing using SAP Event Stream Processor (ESP) with SAP MII is explained in this blog by
Sam Castro.
Centralized HANA as Analytics Hub
It is also possible to have HANA as a central instance with MII installed on traditional databases (may at each production site) and pushing the
data from MII to HANA central instance for long-term and heavy analytics. This is more suitable when having MII deployed at each plant and is
the same architecture followed by SAP OEE solution. This way the central HANA instance collates the data from individual instances at each
plant by SLT replication, and can provide cross-plant analytics with drill-down and comparative metrics. But when it requires plant hierarchy
(PIC) to be used or other configuration data from MII it may be a bit difficult to replicate the same from MII, which may need creating additional
complex data models in HANA.

As I understand there is not any major enhancement done on MII 15.0 product for leveraging the power of HANA, but still it can use its massive
storage and faster analytics capability as explained above. But it may need fairly good level of HANA development skill rather than only MII
development skill. I am expecting to see more tighter integration of MII with HANA in the forthcoming releases to leverage the HANA features
to the maximum extent possible from the MII platform itself.
As a conclusion I can say it definitely looks promising having HANA with MII to provide high-performance analytics on manufacturing
operations and deep insights on trend and help in predicting and providing early warnings, but MII as a platform should also need to get
matured more to leverage the capability of HANA to the fullest extent.
As of now if MII is installed on HANA, trend and KPI analysis on long-term and large amount of operational data may be some of the quick
scenarios to try out.
I had some quite interesting discussion with Sam Castro and Rajeev Kansal on this topic in this forum thread and also like to know about
others' viewpoints and experience on this topic.

SAP MII, HANA/ESP and Lumira (Technical)

created by

Salvatore Castro

on Sep 25, 2014 10:11 PM, last modified by

Salvatore Castro

on Dec 12, 2014 4:51 PM

Version 6
inShare

Overview
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.

Deployment Options
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:
1.

MII 15.0 on NetWeaver (AS Java) using HANA as the DB

MDO, KPI & PIC all utilize the HANA DB

2.
3.

4.

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

5.

6.

7.
8.

PCo 2.3 streaming data to SAP ESP and ESP pushing into HANA
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.

Architecture(s)
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

Central Deployments
A centrally deployed MII environment (Note: MII 15.0 supports the HEC environment) is common to see for the handling the following
scenarios:
1.
2.

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

3.

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

On-Premise Deployments
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.

Architecture Diagrams
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:

SAP MII & ME : On-Premise (Discrete Manufacturing)

SAP MII : Central and On-Premise (Process & Continuous Manufacturing)

SAP MII : Central Only (Typical for Pilots, Bldg Mgmt, Upstream O&G, and Utilities)