IS MDM the same in in the Industrial space as in Enterprise?

Following on from last week this is a good question that may take a couple of weeks to explain, debate.

Synching between systems, I see 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 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 realised, 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 modelling 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 standardisation 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 visualisation and the retraining of operators. The question is, once the naming standardisation 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 realising 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 standardised 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 standardised 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. Standardising 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????

Does Master Data Management does it Apply in Industry

 This again most automation engineers and plant personal look at me with a "blank look". But those in the business side / IT understand the need and challenge. But the real question does this have a chance to really work in the operations level 3 space, let's have discussion around this.

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

"Master Data Management (MDM)

The third proof of this conservative thinking is that very few manufacturing technologists have ever heard of Master Data Management (or MDM) and fewer understand what this actually mean. Enterprise solutions have long relied on MDM systems to ensure naming consistency and data translation between disparate enterprise-level solutions. Manufacturing has not even given this a thought as can be seen by the proliferation of point-to-point interfaces between systems."

Around the 2000 time, I like many of the MES linked people were looking at how to integrate to ERP systems through EAI etc, and we found ourselves on many inter- operative meetings. Discussing how bring S95 to reality, how can lower the risk, and engineering in this interoperability. Now 10 years on the EAI approach has worked for some companies, but as one of them said to me that 10% of the challenge and inter operative communication, synching is between the ERP and MES/ Operations. Actually 90% is at the ISA level 3 and it is as another company put" the invisible barrier, limitation to achieving industrial agility".

 

So what are we referring to is that there are so many applications in the operations areas which will come from different vendors or the different applications are focused on their area that their model approach is so very different. Yet for agility these different operational applications need to stay current and aligned, today this is ver manual alignment or custom code. Example I had one customer talk about DCS to Historian, and MES they make 16000 changes in their DCS systems every 6 months, and how do they make sure the configuration changes align across these 3 systems. Example if you have these three system modeling the same tank, one system generation alarms, one history, and the other batch, the size of the tank is key to all three. Now the plant is changed and the tank capacity is increased now one system is changed eg DCS but the others are not because they do fall under responsibility of the plant engineer. There is no system to say that there at least systems that depend on this master data, so many companies would start up totally unaware of the possible dangers. One company commented they find 80% of their miss alignment after start up.

This is where the opportunity for "master data management" comes to the front in industrial systems.

But some people state that we need to do is put all master data in one DB and every system access this, I would challenge this is not the correct path. It would lead to duplication of data, and performance and sustainability night mares.

The manufacturing data management needs to be a reference capability that allows the core data and models to stay in the original systems, and awareness of updates that are needed.

You should be asking yourself how can you do SOA and the service bus approach without this “industrial master data management" capability, especially when it goes outside the known data models and you use the SOA to federate external applications with their own data models.

Yes it is needed, I have seen at least 8 projects where different custom systems are being built. But all of these are custom, and really just links, and have little chance of being sustainable.

I hope I have opened food for thought.

Now that I have started the thought process we can expand next week, expand on my views and Gerhard's  how this applied in Industry, as the industrial market needs to open up to looking at tools to manage this. 

Remote Diagnostics Monitoring logical for Preemptive support, and Higher Availability.

I talked about last week the influence of IT on the strategies for System Administration/ Diagnostics with respect to drive towards using off the shelf IT tools for System Admin such as Microsoft’s System Center.  But there is another trait form It coming into software and that is the desire for pro-active monitoring of the software systems, vs the traditional just logging of systems.

I was in an executive meeting a couple of years ago in Southern Africa, where we had a number of the CIOs from some of the world leading companies and we discussed the shortage of expertise, the outsourcing of IT and engineering, and the increasing complexity of solutions, and most of all the ever changing evolution of modern software components of a solution. These brainstorming discussions around one table with a set of leading thought leaders , brought up challenges and opportunities.

One of the key challengers was having expertise on internal teams that understood the error measures , best practices and can stay up to date, as it is hard to (impossible to have dedicated people) to one system or product. Now this has been solved by traditional database companies, and systems, by these companies providing a diagnostics / monitoring service that pro-actively   the site systems, with a dedicated team of product experts, who are up date and can dedicate 100% of their time to staying up to date. In the "Business Applications Software" segement and in DCS hardware, and High availability hardware companies this has existed for a long time, but  not in the traditional automation software sector. But again in the last 2 years we have seen this practice, or service come being offered.   

Already Invensys Southern Africa  has set up and is offering this service as an Invensys Sentinel service:

“As skills scarcity increases, most production technicians are stretched to the limit with their Daily tasks. Little time is left to maintain the running software systems and very few can find the time to develop and maintain specialist knowledge to diagnose faults on these systems.

As a result of this change in market conditions, Invensys offers Sentinel Services (ISS) technology that monitors the performance of your Wonderware system — continuously.

Invensys delivers the following Sentinel Services capabilities:

·          Continuous proactive monitoring

·          Remedial remote diagnosis support

·          Wonderware system health review

Command Center in South Africa

We achieve this by installing special “agent software” on each Wonderware server located at customer sites. These agents monitor the system on a 24x7 basis to ensure that critical resources are performing within best practice norms.

If an unacceptable threshold is reached, an alarm is raised and Invensys engineers are alerted before an issue develops. Remote connectivity is also designed to ensure that, if there is a problem, Invensys experts can work with you to make appropriate adjustments to correct the issue and return your system to normal operation quickly and easily.

It is typical of the innovation of the Southern African team, and you can expect to see this evolve into a main stream offering over the next 12 months.

Again these CIOs (eg IT) had an expectation of the fact they can monitor their business datbases and applications and systems by external services with with the expertise WHY NOT in the automation/ operations software. Another example of impact of existing IT practices and it been adopted as an acceptable practice in this automation sector.

But I would question the need for just monitoring we want to go to exception based awareness of the software systems, and treat these as assets in your production system just like the your large capex assets such as furnaces, bottling lines, pump stations, WHY NOT? I would like to start down this topic this week and expand to making Software apart of Asset Maintenance strategies.

What is the influence of IT on System Administration/ Diagnostics Approaches in Automation/ Operations  Systems?

The continued transformation of the automation/ operation systems under the significant influence of IT continues 14 to 15 years after the influence started to be felt during the “year 2000” panic and awareness. To me the most significant impact of this period was that corporate IT become aware during the software audits of the amount of desktop/ and servers running on the plants. From this time I have sat in many meeting where leading company IT engineers have discussed how they can bring more management and therefore sustainability to these systems.

The pressures on these trends / discussion continue and for good reason:

·         Security and threat of cyber security attacks down in plants is now not a dream but a reality

·         The continue stream line of IT and driving the IT cost down through outsourcing.

·         Also the never ending annual, and sub annual upgrading of OS especially now that most automation/operations systems run on Microsoft Operating systems, there is a treadmill of upgrades, due to security and technology evolution.

These are to name a few, and this is so different to 80s and 90s (when many of the current automation systems where originally developed), where the OS was isolated from these outside effects.

But the above pressures will not go away, no matter how much automation engineers “dig their heads in the sand”, because the reality of:

·         information distribution to a much bigger audience in the plants

·         alignment between operational and business

·         operational empowerment

·         driving of cost out of systems

·         increasing reliability

are only going to grow.

So in the last 12 months I have been increasingly asked and internally we evolving the System Administration/ Diagnostic functions to be not built by likes of the automation vendors like Invensys, but for our systems to plug into the System Administration tools already adopted by IT to manage their overall backoffice and server systems. To be honest this makes a lot of sense, as these tools Microsoft System Center, IBM Tivoli, etc, as they are rich in administration functions and are understood.

So now if we take or existing:

·         Licensing management

·         Patch and software version management

·         System Diagnostics

·         Security Management

Extending it with the virtual machine management, which is becoming a natural way for deployment in automation and operational systems, but with no overall co-ordination.

This all seems the natural evolution for the automation vendors including DCS/ PLC control system administration to be developed into services that naturally run in these powerful IT System Administration tools, extending them with the industrial domain.

Another aspect we seeing is the remote diagnostics outsourcing of automation/ systems to a remote expert systems that pro-actively monitor the systems and engage the plants in a pro-active way. This I will walk through next week, but again it is a natural concept that has come from IT.

Why SOA in industrial/ manufacturing space?

This is a question I have heard a lot, I have also heard SOA been thrown about in  Industrial market limited real understanding of the potential value.

So this week to add to the discussion I have included an extraction from “When last did you revisit your MOM?” By Gerhard Greeff – Divisional Manager at Bytes Systems Integration

“You may think that the SOA concept applied to manufacturing is outrageous and that it will never work. After-all, you have talked to the Enterprise Architects and they just don’t get the complexities of the manufacturing environment. But before you skip this section, do yourself a favour and read what SOA actually does according to Gartner and MESA and then think how you can apply that to manufacturing and MOM specifically.

A number of companies (including manufacturing companies) have implemented Enterprise Service Bus’s (ESB’s) specifically to ease integration. These ESB architectures have not however made their way down into manufacturing itself, and with good reason. The enterprise layer (level 4) and the manufacturing layer (level 3) are not the same, don’t work the same and have completely different priorities, data types and business processes. Only a fraction of manufacturing process data make its way up to the enterprise level and then typically only in aggregated form. A lot of manufacturing process data however is shared within levels 1 to 3.

MESA for instance states, “For MOM, a separate manufacturing services bus (MSB) is required due to a high number of transactions, a high parametric data load and near real-time requirements for operations applications. The MSB may be scaled down to a plant or an area of a plant or across multiple production facilities depending on the transaction/data load and response requirements of the operations workflows being supported by the plant applications.””

These comments I agree with, and the more you look and investigate what the leading thought leaders in industrial companies they are trying to solve this massive challenge of inter-operability at level 1 to 3 and horizontally across these levels. But unlike level 4 there will not be domination of one system, or a few, there are just too many specialities. The challenge is also the criticality to life, and operations, that these different systems cannot evolve at the same pace. As explained above SOA provides a infra-structure that allows this alignment, but at an evolutionary approach.  But the critical item is that services need to abide by the service structure, so they align, so others implementing that contract/ service can consume or contribute to that inter-operability. The concept of a separate Service Bus for the industrial sector is correct, when you look at the determinism, and performance needed. But can a service bus perform as we come to trust in this market. I am pleased say Invensys has been working down this service bus for the industrial market and before the end of year will release a true service bus that performances as we expect or are use too. But this is only an initial step on this road, as we move into this “federation” vs replace mode and look at the real opportunity we have when we align the assets, people, systems and applications especially horizontally at level 2, and 3.

“SOA architecture allows for the creation of composite business applications from independent, self-describing and interchangeable code modules called “services.” These services are available for use on a services bus and can be arranged into a business process or a composite application using process choreography. When SOA is employed as an integration strategy, it brings about a catalogue of self-describing, atomic business services that are used together to create a business process (including manufacturing operations process).