Can we have the internet of things with operational data management?

We all talk about data from different devices etc. This is well and good but can you really have effective information if the data is not in context?

The challenge is how you gain this context and then sustain this context over many devices (things) without significant impact on the devices, how do add, remove and evolve devices (things). The role of an operational data management system that is a “yellow pages” of the system, providing the context, and relationship between devices and the operations.

Providing the ability to register new devices and associated data, input the associated context, while maintaining the detail in the device, but provide the bigger operational process alignment. This will also provide the association, other naming of that device so other applications, roles can find and interact. Often other systems, machines have a different outlook on the process and will use different naming and referring for the device. The Operational Data Management capability provides this association and ability to align many devices without having change the underlying applications or devices.

From a data to information point of view it provides the contact to gathering of data to shift it to information, so that big data analysis and other tools can be applied transforming that information into “knowledge”. Providing a pattern for contextualized operational data (e.g.: production, quality, machine status, etc.) integrated to templated collaboration activities (ODM) and ultimately broader supply chain management.

Without this companies have a real opportunity of just gathering significant more data without creating or having the ability to create the associated proportion of Information, knowledge and eventually wisdom. The diagram above shows the knowledge management pyramid and how on the right hand side companies have not go the top one which is blow out in data without the associated knowledge. The leaders will put architectures and systems into place which enable them to gain the contextualization while providing the “plug and Play” ability for devices and things to be added to the solution.

Which path are you on, how are you addressing this ODM concept?

Third Time Lucky for MOM/ MES Architectures?

For the last 15 to 20 years companies have implemented MES (Manufacturing Execution System)  systems, and MOM (Manufacturing Operations Management) systems, remembering MOM is a super set of MES. These implementations executions have been both custom, and using off the shelf applications for MES, and success has varied, but even the successful ones are struggling to evolve to current agile requirements due to the method of implementation. One end user asked me on the flight “has MES been successful?”, I stepped back and thought about a couple customs who have implemented end to end MES. Based on one MES system so that manufacturing master data is managed by one system, with the customer stating their MES has been the most valuable software implementation on the plants, it just works and is the heart of their manufacturing. So the answer is yes, but the fact of the question allowed me to reflect on the normal bumpy roads MES implementations have had.

I was read Charlie Gifford’s latest book “The MES Chronicles” (ISA 95 best practices book 3.0), which has a set of articles around Gartners’ Manufacturing 2.0, explaining the concepts, and reality to the concepts. It is well worth the read if you are looking at the industrial/ manufacturing operations space.

 

 

In the introduction,  Charlie does an excellent job raising the challenges of MES, and the fact that we now with Manufacturing 2.0 going through actually the third architectural attempt at MES. How true his comments are when I reflect on my own career which had gone through all 3 since 1995 when we released InTrack (original MES Product).  A key consideration to this discussion is that MES is a concept of managing the executing the manufacturing, with the off the shelf solutions and customer systems built for a particular industry  with rules and practices for that industry. So looking at Invensys’s first generation MES system InTrack it was built for the semi conductor/ electronic industry, and the outstanding success stories I referred to were from that industry. Invensys’s second generation product built Wonderware MES for food and Beverage industry, and again has worked remarkably well in that industry and related industries. This does not mean they cannot be applied in other industries, but the “glove fits well”. That is why I do not like the generalization of MES, we should categorizing them by industry types, to help selection, and stop companies force fitting the wrong models into their practices.

Charlie in his book reflected on the three generations of MES/ MOM as:

“20% of advanced manufacturers discovered that the first two MOM attempts lead to:

• High cost MOM systems with extremely poor data integrity
• High cost change during new production introductions, production scaling time to market and continuous improvement.”

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

His % might be low, but the point is that MES / MOM solutions have typically been architected in a “point to point” / application integration, with high levels of customization restricting evolution to the original developer. Many of the original InTrack MES implementations have maintained the database well, and the rules within it, but significant custom code has been developed for human interaction and data validation, and data validation on automated events acting on the system.  Like highly customized ERP implementations the ability to evolve , upgrade the systems become an anchor on manufacturing agility. Yet that is the reason why people put these systems to increase efficiency and consistency of production, but the issue is manufacturing practices, new product introduction is constantly changing and evolving, and the systems must be able to absorb this change naturally if the implementation are going to allow for the required agility needed today.

So the third attempt at MOM with the Manufacturing 2.0 concepts undoubtedly lead to:

·         An SOA (service orientated Architecture) that allows plug and play of the 15 to 20 Operational applications required to run a plant, allow the inter-operability to set up using messages through sustained services vs application integration.

·         This integration is a model based using tools such as workflow and sustainable environment.

·         Validation and data entry rules will be model driven, so that embedded best practices, that can evolve in a sustainable way as staff evolve in the organization.

·         Semantic information, and data management models based on proven models such as ISA 95 will enable existing and different models of the different operational applications to align.

The book outlines many of the concepts. MES are not a standalone product, it is  an architecture that merges level 2 events from automation, with validation of data, events in a structure asset/ operations model that can interact with the different operational applications through the life of a manufacturing operation. Key is the acceptance of  architecture which has model driven interoperability (so the model can evolve with governance) and the introduction of workflow to be a natural part of the operational system to capture the procedures as embedded operations that again have governance so can evolve as the practices of the plants change. Like successful ERP implementation, customization must be avoided, configuration within the tools provided make the system sustainable, but this will be a mind shift for people. Too often people talk about APIs, and taking coding tools to build a solution, this is fine for the short term, but will come back and bite when time for change and evolution. The project and program owners at the end users need to take a more holistic view and enforce an architectural cadence of configuration vs programing and making sure the “human to application”, and “application  to application” integration are model centric approach where configured services  using workflow configuration is key.

 

 

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????

 

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.