Commentary Feedback on “Third Time Lucky for MOM/ MES!!!! YES, it does have a significant chance this time!!

It is an interesting writing this blog as there is little comment feedback in the blog, but I receive a lot of email on certain subjects with substantial input. The topic of “Third time lucky for MES” I received a lot of both email and discussion face to face, this blog expands on the topic.

The first comment from many people was “that MES has been around for years and has been implemented successfully”, and I agree, but the first 2 generation architectures involved significant services while they have run extremely well for a number of years, but with limited ability to absorb change without significant cost and risk. Also, companies are expanding in multi sites and the requirement to enforce operational practices over multiple sites, again this requires alignment of sites. So yes MES has been successful in concept, but not in a sustaining mechanism.

Charlie’s comment in “The MOM Chronicles” reflects this:

“The first two MOM attempts occurred in the 1990s, and 2000s, actually were also found a primary hindrance to continuous improvement efforts because the MOM system owners were typically understaffed, under skilled, and un governed to support real innovation. “

So what is different this time? Was a common question, as mentioned in the original blog the SOA (service Orientated Architecture) actually been adopted correctly with conforming service contracts at the ERP side and business side with the “Enterprise Service Buses” (ESB) becoming a norm, not just a term. This flowing down into the operational world with vendors looking at aligning with web services, but also model centric alignment vs point integration is key. The figure below taken from “The MOM Chronicles” illustrates the concept:

The experience we have MES implementations at Invensys has pushed us to evolve our architecture, and the key areas are:

1/ The MES functional Capability has evolved in richness

2/ The plant events are now linked into the System Platform, using templates so now plant equipment and events can be templates and managed, also validation is achieved as close to source as possible.

3/ The Human interaction and the business rules and processes are no long programmed they are implemented in a model driven (workflow) environment. So now face plates/ forms that present information and interact with humans validate the data entry as early as possible and with no code but in graphical modeling environments. This area alone is transformational as I have sat down with process/ operational teams with these graphical workflows and worked through with them relative to their process, we mark up the diagram and implement fast. No longer programmers are involved in business rules it is the operational/ business / process teams work know their rules and behaviors they require and they implement.

The diagram below shows the realization of the aspects of the Invensys MES architecture, and it is all three aspects that make this a sustainable solution, that scale, and also work in a multiple site situation. But most of all it is agile aware been able to absorb change.  Again this is a different approach to tradition MES solutions which have at MES Functionality, but honestly depended on coding around the system for events, human interaction and business rules. This architecture is SOA so it is plug and play and services like the MES can run in different locations, leaving open the opportunity for MES data bases and rules to run in an elastic “cloud”, combining with the on premise interactions with the plants and people.

 

Disruptive opportunity with transitional actives (FAT, training, simulation) for industrial space

As the weeks go on the discussion continues to increase around the opportunities, and growing consideration of Cloud playing in the industrial automation and operations architectures within end users. One of the emerging realization of opportunities in the transitional activities on bringing a plant on line, such as commissioning and operational learning. Not been mission critical activities, as one person put it “why would you want buy and set up hardware for activities such as FAT (factory acceptance testing) or training simulation for only 2 to 3 months?”

The concept of a virtual FAT environment is not new, what is intriguing is the fact that the “cloud” offers expandable (elastic) computing engaged for a temporary period on a monthly plan. Too often the limitation on FAT efficiency is availability of hardware, due to project budgets of purchasing hardware , no flexibility to expand and then the hardware goes to site, restricting the offsite testing and the ability to have multiple FATs happening at the same time. The cloud can easily host the virtual images of servers, control simulators and different workstations of a plant.

Key is that an engineering house can provision the required computing capability in days and test out the loading required computing power required by the application via a cloud virtual environment. They can create a temporary FAT or development environment in the cloud, which can exist for the life of project build, costing is leasing, the system can expand as the project grows or goes through different stages. This is different to a virtual environment in that the computing power in unlimited, and it grows and shrinks with the requirement and it avoids out of date hardware with no home.

Another end user discussion is relative to training simulation. Traditional OTS (Operating Training Systems) programs expect a long term steady state of training capability, but as the initial project go live, and the evolution of existing staff, and associated staff they have a temporary requirement for significant operational and worker training systems, and again " cloud seems ideal for this". The fact that a simulation OTS can be set up and then expanded, accessed from different locations, and then dismantled after the demand drops without the need to by unnecessary hardware is key.

Both of these examples are not earth shattering, but the discussion and questions show a shift in thinking. I am fully of the belief that a typical automation/ operations architecture which spans geographical boundaries and even within a plant, will be a HYBRID architecture in the next 3 to 5 years. With on premise set of applications, (probably upgraded versions of the existing ones on the site today), and with a set “cloud” based applications either on private or pub that work in a complementary fashion with the plants. Providing additional richness to the site applications with extra computing power to execute applications such as simulation (“What if”), for training, knowledge systems, and cross plant applications such as history, information, and decision support. The development of security architectures that accommodate the cloud for industrial space, where security access is handled external to plants fire walls, combined with the plant firewalls, providing significant security.

Another example comes from a recent paper from Analysts ARC on MOM/MES customer interviews which stated:

“Another implementation timesaver to look for is the availability of cloud-based MOM/MES system for development. Compared to waiting for on – site servers and data bases to be acquired, deployed, and configured; the cloud-based  system can be often be provisioned in a few hours so the team can get right to work. If templates are also used stake holders can immediately begin to make system decisions that otherwise might take weeks or months to reach and base these on the best possible information, the actual system behavior.”

As we have seen over the last 6 to 8 months the discussion grows around using the cloud, especially as the cloud based industrial applications continue to be released to market, and the next 6 months will see a step increase in these. The time has come to understand what the requirement is for the  business ,then ask the question which is the best way to implement this in a scalable and affordable low risk manner.

Can Sustainable Manufacturing Operations Management Exist without Master Data Management? NO,

Again last week the discussion of operational integration raged in few project discussions with customers, without really understanding the arguments and I needed to pull out a log from mid last year on Operational Data Management. Data Model Alignment will be key in a viable interoperability architecture for level 3 applications with out “rip and replace approach” in making Manufacturing Operations Management sustainable and effective.    

Synching between systems, people look at data warehouses , they do manual binding, but these are just not practical in a sustainable and every changing world. There are many systems usually upwards of 20 + systems which come from different vendors and even if they do come from the same vendor they implemented by different cultures in the plants. The thought pattern on “just asset naming” is different between these groups. So the concept of Master Data Management (MDM) for Industry is a hidden one, but we believe is a key one for the future of sustainable solutions that are federating multiple systems together, so expect to see investments and products to trying to address this. In this blog I want to have a discussion on why MDM what it is, and Gerhard has done a good job, and I will expand on it.

 

When you are talking to customers you see comments and projects and so many are trying to deal with this issue without really looking at the big problem and plan. The same issue of naming happens with Assets between the Alarming system, MES system, Batch System, and EAM system for example. The capacity or size of a asset(Eg Tank) is key to their operations but often changes are made to the actual asset and then say the EAM and alarming systems are updated but the others are not realized, and the plant starts up with half the systems updated. Yes now you get faults and plant delays, and trouble shooting. Imagine having a system that is aware of all the systems that are modeling an aspect of that asset in their data models, now you can have a “master change management” over it been changed at one location and making sure it is changed at all systems prior to start up, even if updates are manual.

Again Borrowing from As Gerhard Greeff – Divisional Manager at Bytes Systems Integration put it in his paper"When last did you revisit your MOM?"

“MDM or Master Data Management is the tool used to relate data between different applications.

So what is master data and why should we care? According to Wikipedia, “Master Data Management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional data entities of an organization (which may include reference data). MDM has the objective of providing processes for collecting, aggregating, matching, consolidating, assuring quality, persisting and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.”

Processes commonly seen in MDM solutions include source identification, data collection, data transformation, normalization, rule administration, error detection and correction, data consolidation, data storage, data distribution, and data governance.

Why is it necessary to differentiate between enterprise MDM and Manufacturing MDM (mMDM)? According to MESA, in the vast majority of cases, the engineering bill-of-materials (BOM), the routing, or the general recipe from your ERP or formulation/PLM systems simply lack the level of detail necessary to:

1. Run detailed routings through shared shop resources

2. Set up the processing logic your batch systems execute

3. Scale batch sizes to match local equipment assets

4. Set up detailed machine settings

This problem is compounded by heterogeneous legacy systems, mistrust/disbelief in controlled MOM systems, data ownership issues, and data inconsistency. The absence of strong, common data architecture promotes ungoverned data definition proliferation, point-to-point integration and parochial data management strategies. Within the manufacturing environment, all this translates into many types of waste and added cost.

The master data required to execute production processes is highly dependent upon individual assets and site-specific considerations, all of which are subject to change at a much higher frequency than typical enterprise processes like order-entry or payables processing. As a result, manufacturing master data will be a blend of data that is not related specifically to site level details (such as a customer ID or high-level product specifications shared between enterprise order-entry systems and the plant) and site-specific or “local” details such as equipment operating characteristics (which may vary by local humidity, temperature, and drive speed) or even local raw material characteristics.

This natural division between enterprise master data and “local” or manufacturing master data suggests specific architectural approaches to manufacturing master data management (mMDM) which borrow heavily from Enterprise MDM models, but which are tuned to the specific requirements of the manufacturing environment.

Think of a company that has acquired various manufacturing entities over time. They have consolidated their Enterprise systems, but at site level, things are different. Different sites may call the same raw material different things (for instance 11% HCl, Hydrochloric acid, Pool Acid, Hydrochloric 11% etc.). Then this same raw material may also have different names in the Batch system, the SCADA, the LIMS, the Stores system, the Scheduling system and the MOM. This makes it extremely difficult to report for instance on the consumption of Hydrochloric Acid from a COO perspective, as without a mMDM for instance, the consumption query will have to be tailored for each site and system in order to abstract the quantities for use.

The alternative of course is to initiate a naming standardization exercise that can take years to complete as changes will be required on most level 2 and 3 systems. That is not even taking into account the redevelopment of visualization and the retraining of operators. The question is, once the naming standardization is complete, who owns the master naming convention and who ensures that plants don’t once again diverge over time as new products and materials are added?

The example above is a very simple one, for a raw material, but it can also be applied to other resources, utilities, equipment, operating parameters, recipes, WIP and products. If a company has for instance implemented a barcode scanning solution, the item numbers for a specific product or component may differ between suppliers. How will the system know what product/component has been received or issued to the plant without some translation taking place somewhere? mMDM will thus resolve a lot of issues that manufacturing companies are experiencing today in their strive for more flexible integration between level 3 and level 4 systems.

Figure blow shows the relation between mMDM, MDM, SOA and SOAm and how they are meant to operate together.

The objective of the proposed split in architecture is to increase application flexibility without reducing the effectiveness and efficiency of the integration between systems. It also abstracts the interface mechanisms out of the application into services that can operate regardless of application changes. This will get rid of numerous “point-to-point” interfaces and make systems more flexible in order to adapt to changing conditions. The SOAm architecture also abstracts business processes and their orchestration from the individual applications into an operations business process management layer.  Now, one person is able to interact with multiple applications to track or manage a production order without even realizing that he/she is jumping between applications.

Even with SOAm and mMDM, integration will not be efficient and effective unless message structures and data exchange are in a standard format. This is where ISA-95 once again plays a big part in ensuring interface effectiveness and consistency. Without standardized data exchange structures and schemas, not even mMDM and SAOm will enable interface re-use.

ISA-95 provides standards for information exchange as well as standardized data structures and XML message schemas based on the Business-to-Manufacturing Mark-up Language (B2MML) developed by WBF, including the verbs and nouns for data exchange. Standardizing these throughout the manufacturing operations ensures that standard services are developed to accommodate multiple applications. “

Why not a central directory “Yellow Pages” that manages this relationship without replication????