Issues and Concerns with a centralized MII Architecture.

[Former Member]

I have a customer who is looking at having a centralized MII architecture that would use one MII server to serve out several plants world wide. The data sources will be an Oracle RDBS (centralized) and an Enterprise OSI Pi system (again centralized at their datacenter)

Just to be clear I am NOT recommending they do this, however as consultants you know how it goes. I have raised the issue of local survivability but that doesn't seem to concern them much for this application.

Some concerns that I have.

Number of users could potentially be upwards of 1000 concurrent users. How well will MII handle this?

Multi Language support for the client. I'm pretty sure this won't be an issue, but asking anyway.

Time zone issue for clients (Data will be stored in UTC) but the users will want time to be localized.

Transactions. This is an OEE type application, so there will be some heavy transactions.

Anyone have experience in this type of landscape or other issues that might pop up?

This will be 12.1 using UDS or PCo 2.1 when it come out.

[Former Member]

One more point to consider would be the Data Sources , like you say if they reside , lets say @ the corporate then it would make sense to move forward with a centralized approach.

For performance with 1000 concurrent users make sure you have fair amount of horse power on the MII server . Sam Castro has come up with a performance testing white paper , comapring 12.0 & 12.1 . Make sure you go through that. You can access the document in the "guidelines" section of the MII Wiki.

Hope this helps.

Thanks

Udayan

[agentry_src]

Doug,

I sympathize with the sometimes quirky requirements of the customer, but that is the life of a system integrator consultant. I would add that the OEE calculations would be more efficiently performed within either the individual plant historians or at the very least at the Enterprise (PI) level. That, by itself, would greatly lighten the load on MII at least for the OEE calculations. Not sure the customer will agree with that approach (process engineers tend to be protective of their manufacturing environments), but it really works better to push the calculations as close to the original data as possible. Besides Performance Equations (in PI) are pretty easy to build.

Regards,

Mike

[Former Member]

Hi Doug,

The main drawback about having a central MII is the communication between MII and the other parts. There are 3 kinds of data transfers: to SAP, to the Source systems and with the users.

With a central historian communication to the source systems is not going to be your major concern, though on the historian side this can be, neither will be to SAP as it does not seem to be part of your OEE architecture and anyway it is central.

For the user part youu2019ll have to consider some points:

- Limit direct query to your database or the historian triggered by the users. In order to do this you can;

o Schedule transactions which are going to query the information and use the cache information in your reports. With this you decouple user load with OEE processing or aggregation.

o Create reports on a regular basis with scheduled transaction. You can use an iframe to direct the user to the latest report. That can be every 2 or 3 mins. The load for the report will be per site and per number of report by time. Not by number of users which can frenetically refresh their browser.

o Limit the number of applets used in the page use the Servlet in the irpts. You will be able to transmit all the information in a page that will only be a few Ks. Of course itu2019s not always applicable and will depend on your requirements.

o Also it is better to have too much information in your page (without being excessive) rather than re-quering information. For your 1000 users the latency (network + processing) will come when you query the information, if it is already there then the browser take care of displaying the information. This also provides you a better scalability toward the number of users.

- Regarding internationalization youu2019d better use keys that represent type of information and resolve them on the page with the MII tokens. That will also provide a single point for the translation of the pages.

Also I completely agree with Michael doing complex and resource intensive calculation in MII with 10000 records does not fly, for the leastu2026

Cheers,

Arnaud

[Former Member]

Another issue is that depending on the nature of the application, storing and manging data for multiple locations in one database can add complexity to data model, or even the data access model ( e. g. assign data sources to users dynamically )

Security can be another. For example if you have 4 plants and you need to be able to have users that can only access say plant 1 and 3 but not 2 and 4 you have to start adding your own securty checks etc.

I have done both. A central arhitecture can work fine but in my experience you do spend some more design and development time.