A New Approach is Required to Enable It/OT, with Information Driven Systems!

Two weeks ago I wrote about IT/OT convergence, and some thoughts, while the convergence has been happening for years.It seems only lately that we running into the significant step of changing the organization from tradition structures to a modern / new generation Operational IT approach. But the interest in that blog post was significant, with many hits, and many direct emails on ideas, comments.

The fact that 4 significant companies I have visited lately that we find that the head of the traditional IT team, and strategy is someone from Operations, with limited traditional IT experience, but huge amount of Operational and Business experience. The strategies are now not about the technology they lead by an business/ operational value, and how do deliver solutions fast, and efficiently, with technology and systems that are sustainable, and evolutionary.

In the information driven space this is giving rise to a different approach:

Strategies are more than technology, the key is operational cultural transformation that includes device, equipment integration, with people, and alignment and repeat ability through process integration. Leading to strategies as seen below.

The strategies require a focus on accessing the correct information, in context, and understanding the business process design, building on repetitive foundation of standards that can evolved. Understanding that standards and a platform is key to maintaining the evolution over multiple vendors.

Below shows a concept of the three levels of maturity on the journey that is required to bring information under control and effective. This aligns with the “Knowledge/ Wisdom” discussions we have had at the end of last year.

How many of you are moving to platforms for aligning multiple vendors, while moving away from custom code to configured standards for information context and procedures?

Mastering Variety in Industrial Production, Issues a Challenge for Industrial Architectures and Drives the Requirement for Platform Strategies

For many businesses, variety (or choice) is core to the strategy where its effect cascades down to the execution level (as well as upstream in the B2B value chain.) The operational challenge of variety (or variability) is that it can create waste and inhibit velocity. The challenge and opportunity is with companies, especially as they move to unified value chains (multi plant manufacturing). “How do you manage this Variability, so that production consistency, agility and increased production output are achieved?”

“Standardization is not a business goal – it is a means to an end.
The goal of business is to make a profit.”

                                                             - Continuous Improvement Leader

Thus, any standardization effort must distinguish between the different types of variety in a way that maximizes profit without constraining the business strategy. Thus, the business challenge can be summed up (using the Food & Beverage example illustrated on the above) as follows:

• Mastering necessary variety: More brand choices drive the number of order line items (SKUs) and master recipes, which in turn drive the resulting plant-level recipes that must accommodate the variations in process equipment as well as ingredients. This type of variety is necessary and must be mastered in order to survive and succeed against the competition. Other “necessary variability” are material composition variance from different suppliers or regions, raw materials will vary. Location delivery in skus due to language, for example, the same product will have to be delivered to different countries in different language or different quality requirements. All must be mastered to optimized production.

• Accommodating unavoidable variety: Situations like M&A make it difficult to standardize on any single automation vendor, where “rip-and-replace” isn’t economically viable despite engineering’s desire for a more homogeneous environment. The growing one in this area is the “changing workforce” how do have a system that can accommodate a changing, (rotating) workforce while maintaining timely decisions and consistency in actions.

• Eliminating unnecessary variety: Anything other than the above two scenarios would be eligible for standardization.

This challenge is driving companies to adopting “platform strategies” that abstract the variability and can absorb variability while provide a platform of services that enable standards to be built on. Providing the architecture for “sustainable innovation” through managed standards that can evolve over time. The word of standards can be operational models in supervisory for alignment of context and structure, as well as operational actions to guide users through tasks in a consistent way. Also, configuration of control strategies should be over multiple vendors, where common control standards for process can be deployed over multiple controllers but managed in structured way.

Does this mean one platform? NO, not for the industrial landscape different layers of the industrial operations landscape have different roles. Providing different services and different ability to absorb variety, but the common services between these platforms must enable them to “tightly aligned but loosely coupled”.

 As we have pointed out the key to success in this dynamic but changing world is the ability to “Master Necessary Variety” in your business, while “Accommodating Unavoidable Variation”, eliminating all other variation for efficiency.

Food for thought!

Federation of Multiple Control Systems is a Key part of the Operational Transformation, It’s time for an “Industrial Enterprise Configuration Environment”

Last week this came up 3 times in a week, customers asked me are we working on a unifying configuration environment that will manage standards for control, supervisory and more over multiple different vendor controllers. We talked about the need for multiple teams, one for templates development, others for deployment and the critical need for version management. You cannot expect to have standards if you do not have strong governance and in my experience this means a tool, and environment that promotes the successful management of standards.

We talk about federation of information across data sources in an information driven manufacturing environment, but an effective operational transformation is about decisions and actions in a timely manner and consistent manner. Too often we talk at the high level and overlook the extensive work required on the plan automation control integration. Most plants are on to at least their second generation of control, in DCS, PLC and SCADA. These systems are mature and functionally immensely rich that they can expand and evolve to satisfy most processes today.

The Modern Automation/ Operational system is not an enclosed system, it will have many controllers of different sizes running different processes, hopefully the correct controller for the correct process. With the evolution of the “Internet of things” in the automation world there is a trend to smaller powerful controllers so each asset/ process has it is own control that links into the higher world. This makes sense as long as there is the ability to federate these controls from a:

·         Naming convention consistency across the controllers

·         Control Standards for a process over different controllers

·         The ability to configure different levels of a control/ process strategy across controllers but deployed to a different controller instances which in many cases will be controllers from different vendors.

·         The ability to automatically configure the integration with the supervisory platform and the controller at the same time, any changes are automatically managed and sustained.

·         Clear governance over the management of standards and versions across the supervisory and controllers

·         Version management is key the ability to manage different versions of standards in the same strategy deployed to different controllers, combined with incremental updates.

·         The End to End System Integrity at the time of deployment, this is the step most people are concerned with as the system must make sure the integrity of the different parts of control sub system are in place, so we have no dead ends on references that can cause controllers to not function. Assumed in this is the peer to peer communication and referencing between controllers of different roles, types and vendors.

Yes, the leaders in the operational transformation while implementing a Supervisory Platform with operational standards and decision support, they are complimenting their investment with an equally often more significant investment in alignment of the existing and new control systems. Their standards, their interfacing and most of all their management of integration and standards.

The new generation “Industrial Enterprise Configuration Environments” will live above the individual vendor configuration systems but enable a holistic management of strategy and standards leveraging a multi discipline team, with version governance naturally built in. When we look at the “Internet of things” this will become key, as we go to “atomic control” at the devices and machines, the thought of learning multiple tools is not practical. The only way in the industrial world will be a common configuration environment that enables standards, and deployment to different device platforms, with governance, and confidence.

Watch this space as we accelerate the innovation in this area, to bring reality. 

Resetting the Way we do Automation/ Operational Projects!

A couple of weeks ago I talked about the 3^rdgeneration MES and the shift to “model driven” in order to absorb change in the operational practices and this drives the shift to develop standards and roll them across plants as well the elimination of custom code.

 Again last week the realization that we need as engineering, and IT that we need to rethink the approach came through in discussions with 2 customers. The discussion really happened around two items:

1/ The speed at which projects in the automation world / operations world need to happen, it is halving as one plant engineering manager point it out. But in his second breath he stated that they no longer stable e.g. you can be sure that the business will drive operational change that will require that project to evolved twice in 12 months.

The discussion was interesting as one of the two in the discussion had grown up in the same environment as I and reflected on the fact that projects use to take a year, they were significant and they stayed in a stable condition for 5 years, this was the basic rule I also found when in Europe and Middle East in the 80s/90s.

2/  The second was the scope of responsibility and rollout, they both commented how they use to be in charge of a team that looked over one to 2 plants, now they run projects that span multiple sites often going outside the country.  The expectation is that the same capability will roll out over multiple sites at a decreasing cost, and decreased time to production. The same changes in the following 12 months must be rolled out, as well.

Combine this with the more complex projects as the level 2 and level 3 merge in the traditional automation levels, the traditional approach to project management and project evolution are not valid.

At the ARC conference in Orlando in February, this same message was echoed by leaders from Exxon, GM< and Nestle.

Sandy Vassar, Facilities I&E Manager, ExxonMobil Development Company used the phrase "it just happens" to indicate his team's goal for the automation portion in each of the more than 100 oil and gas projects now in various stages of planning and execution at the company.

He believes the industry needs "lean project execution," that separates the physical system from the software. Toward this end, the technology suppliers have to think differently and deliver technology in a way that allows the team to eliminate, simplify, and/or automate steps in the overall execution of automation.

He listed the top twelve challenges:

1. Eliminate, simplify, and or automate steps in the overall execution of automation

2. Minimize customer engineering and reduce the total amount of engineering

3. Shift the custom engineering to the software and rely on standard hardware components; progress hardware fabrication independent of software, design

4. Virtualize the hardware and prove the software design against the virtualized system

5. Prevent design recycle and hardware/software rework

6. Eliminate unnecessary automation components and standardize the remaining components so all systems look alike across projects

7. Eliminate or minimize the physical, data, and schedule dependencies with other disciplines

8. Simplify the configuration of interfaces with third-party packages

9. More easily accommodate changes, including late changes

10. Mitigate the effects of hardware and software version changes

11. Eliminate, simplify, and/or automate generation of required documentation

12. Challenge traditional approaches

None of this is unique or new, but like the conversations last week this forum confirmed that a “rethink” is needed, and cultural change. It is important to realize while product vendors must evolve more and more to provide platforms for reuse, and management of standards which provide and en environment for the capture of “Unique Operational Practices”  in a configuration environment that allows evolution and reuse. The engineering community within the companies and within the System Integrator partners need to also evolve to a more agile approach to projects. Compared with the traditional project approach of my site is unique and doing things in a 100% custom way.

The new generation will expect things in a shorter time and will compromise uniqueness for speed and agility! One leading company produced this diagram when they looked at their multi site projects in automation, and it is telling.

I doubt there is no argument on the outcomes, the graphs show 4 key findings (principles):

1/ Integration: across different PLCs and systems, across sites so there is one namespace, one alarms one history one abstraction platform. But integration must be trustworthy and sustainable.

2/ OO Object Orientated supervisory: This is key to have an object/ managed software approach with templates and management of standards at the supervisory and operational level. Key to providing consistent plant model, consistent information, and consistent experience in UI and action as well a platform for the evolution of the system over time.

3/ASM for UI and Alarms: the move to exception based awareness, vs monitoring.

4/ PLC Blocks: again to enable management and standards to allow absorption of change.

This is not new, yet I only see a few companies truly implementing new solutions in this way, which leaves me to ask how will the others deliver systems for the current and future “dynamic world”? 

Confusion Over Standards: Limits or Basis for Innovation?

One of the nice things of this time of year the meeting workload drops, providing the opportunity to do some much needed catch up of reading. An article that sparked some interesting thoughts and is related to a lot of the principles of work and activities. It is worth a read on Toyota’s approach to management of standards around the fundamentals of operational procedures.

http://m.industryweek.com/blog/confusion-over-standards-limits-or-basis-innovation

As discussed at length this year there are a couple of key approaches that will effect industrial operational design:

·         That design needs to move away from interfaces to actually design around activities/ Work; these can be executed through any interface hosted on any device.

·         The other trend is to move to manage / planned work, a knowledge worker moves from a “fire fighting” mode to a 70+ % planned work in a day, which increases safety, and consistent process execution through operational process stands combined with significant cost reductions due reductions in the planned time.

These two trends or approaches will grow in adoption in 2014/ 15 as it is the only practical way to deal with the changing dynamic nature of the workplace and rotating workforce.

The structure outlined below by Jim Laker used at Toyota is a good basis for the how to lay out standards in procedures vs the actual operation instruction. But another key cornerstone of this is knowledge management, with 10000 baby boomers retiring a week in the US, and this rate is expected to sustain for the next 17 years, the requirement for skill vs the talent pool will be offset. So the operational systems must incorporate shared knowledge, crowd sourced and managed to maintain the value. Many of the operational procedures and best practices must be captured over the next 5 years, companies must put a maintainable knowledge management  system, and culture in place, and as you can see in this diagram that standard procedures, operational safety and environment procedures, and practices form the basis for the transition to planned work, and activity based systems.

When you think of standards you think of “handcuffs” on design and therefore innovation, but this is not a logical thought process. How do you enable operational innovation which is based on operational best practices, provides the foundational platform on consistent execution to enable innovation and movement forward. The need to capture operational innovation by taking the best operators and knowledge workers based on years of practices, capture their operational practices within a system so that new less experienced users to adopt the proven practice. Is this a one off NO, this is the continuous process of improvement which will provide the edge for companies to agile.

As you sit down for the Christmas pudding and we look forward to 2014, there is much opportunity and change ahead of us, and these articles provide solid food for thought.

Have a great festive season, and see you in the new year.  

Is the end of heavily customised Industrial Operational Systems here?

“What are you saying came?” A comment back from an engineering house, as I started talking about the end users looking for speed to production of projects and are prepared to compromise customization for this!

Not surprising as their business is built around satisfying end users desires for heavily customized automation and operational solutions, even built on standard industrial products, companies have pushed for the customization of these products to suit the way they intend or operate.

I would challenge that these days of heavily customization are coming to an end, driven by the need to get systems and plants up as fast as possible at the compromise for totally custom solutions.

The concept of “good enough" driven from companies such as Apple where their applications from the store provide “specific” task capability (book taxi, airport flight status, email  etc.) with limited customization and configuration options, yet we constantly adopt them due to risk, and speed of and convenience of now.

There are a number of trends that point to this move to adopt proven completed functionality vs customize:

·         Also in manufacturing people are looking for " plug in and play" process modules units, "skids" that have machinery and control configured and proven and are already tested and commission, so now we just have to plug them together. Example in packaging lines, but even refinery ports where we have had modular solutions with equipment, instrumentation, piping and control for years and just bolted and plugged them together.

·         Multi site companies are driving programs around standards, and then enforcing these to be rolled out and managed across sites and in many case different system integrators.

• So now as look at the adoption of “Managed Services” into the industrial market, we see the need for speed to full production as key, causing people to avoid capital projects/ RFPs and look to gain an advantage by using what is available already as a “managed service”. This has not hit larger companies but certainly is becoming the norm at Tier 3 (small companies) and at tier 2 companies, who want take advantage of the opportunity now. The concept of a set of managed services for:
• Energy monitoring and analysis across all my pumping stations in a water plant or plants
• Production/ process information solution that draws up real time data from many plants and assets and stores it in a historian like storage, with out of the box notifications, rules, and analysis clients that are self service to a wider community. Again this could be across facilities monitoring, unconventional gas wells, pump stations along a pipeline etc.
• Manufacturing operations (MES) for a particular industry that provides manual good/ materials receivables, inventory and WIP management across the manufacturing floor, production order management to CNC machines etc. Again the screens, the forms, the reports are built for that industry, the proven system, the companies provide the master data (customers, products etc), and the rest is available fast as managed services. So a typical MES/ Operations project for a small plant with RFP and definition would go from 6 month to 2 weeks and extremely low risk.

At VM Ware conference two weeks ago again we see the cloud services, and significant discussion that adoption of cloud based services is at the expense of customization. The idea of plugging in a solution and plant and leveraging the design as is will become the norm I believe in the next 3 to 5 years, and certainly provide the edge of agility to those adopt this approach.

Does this mean I think the day of the system integrator is over, NO, they have the unique domain knowledge to build these ‘managed services” and provide the local services to rapidly deploy standards and “managed services”. Yes the way of working in the engineering house will change but I see this as significant opportunity not the other way round!  

Federation of Multiple Control Systems is a Key part of the Operational Transformation, It’s time for an “Industrial Enterprise Configeration Environment”

We talk about federation of information across data sources in an information driven manufacturing environment, but an effective operational transformation is about decisions and actions in a timely manner and consistent manner. Too often we talk at the high level and over look the extensive work required on the plan automation control integration. Most plants are on to at least their second generation of control, in DCS, PLC and SCADA. These systems are mature and functionally immensely rich that they can expand and evolve to satisfy most processes today.

The Modern Automation/ Operational system is not an enclosed system, it will have many controllers of different sizes running different processes, hopefully the correct controller for the correct process. With the evolution of the “Internet of things” in the automation world there is a trend to smaller powerful controllers so each asset/ process has it is own control that links into the higher world. This makes sense as long as there is the ability to federate these controls from a:

·         Naming convention consistency across the controllers

·         Control Standards for a process over different controllers

·         The ability to configure different levels of a control/ process strategy across controllers but deployed to a different controller instances which in many cases will be controllers from different vendors.

·         The ability to automatically configure the integration with the supervisory platform and the controller at the same time, any changes are automatically managed and sustained.

·         Clear governance over the management of standards and versions across the supervisory and controllers

·         Version management is key the ability to manage different versions of standards in the same strategy deployed to different controllers, combined with incremental updates.

·         The End to End System Integrity at the time of deployment, this is the step most people are concerned with as the system must make sure the integrity of the different parts of control sub system are in place, so we have no dead ends on references that can cause controllers to not function. Assumed in this is the peer to peer communication and referencing between controllers of different roles, types and vendors.

Yes, the leaders in the operational transformation while implementing a Supervisory Platform with operational standards and decision support, they are complimenting their investment with an equally often more significant investment in alignment of the existing and new control systems. Their standards, their interfacing and most of all their management of integration and standards.

The new generation “Industrial Enterprise Configuration Environments” will live above the individual vendor configuration systems but enable a holistic management of strategy and standards leveraging a multi discipline team, with version governance naturally built in. I was fortunate last week to review and investigate such a system that is pre –release but represents potentially the most significant step in control strategy/ level 2 / 3 alignment in the last decade.

Modularization Standards enable Fast Deployment and Minised Risk

This week I have met with many engineers from different companies in a number of industries. It is nice to see innovation and people pushing the limits. A company I met built modular solar power plants, and rolled them out over many sites. Due to this modular approach, like the physical plant, they just assemble these plant control, and operational systems. How can this be done with traditional automation systems with tags?

Standards have been talked about in the past, yet I continue to talk with people, and they really do not fully understand them, and value, but also the governance and culture which must go with them. This customer was different, and it was “breath of fresh air”, they saw value, they applied governance, and management.

Standards provide the advantages of:

·          Application reuse

·          Faster project time to Value

·          Reduced risk and errors

·          Reduced commissioning time

·          Provide consistency of experience, operations, control etc across applications

·          Ability to manage evolutionary functionality over multiple sites

 

So what “governance/ culture” is needed? Firstly sitting down and really mapping out the common denominator on the templates what people require, it is better having fewer templates and fewer levels of derivation, but understanding the level, and how it will be applied. This customer has spent time defining and constantly understanding the role of template, the impact of change as they have now rolled this library out over 10 + sites and will roll it over many more, but since they are EPC where they deliver projects to different sites. They are constantly refining the standards, but understanding how they will rollout and impact existing sites, this requires a good capture of thinking why particular functions where added and how they have been used. Sound familiar as it is more a “product culture” than “application culture”! What I mean is that building an initial product and standard is one thing, but as soon as you start installing you have legacy and comes with this responsibility of evolving the existing and new applications. Too many people do not take this into account there are needs for a culture of capturing the requirements for enhancing a standard, from many sites, and then planning version up grades to the standard, the same as a product.

The diagram below shows how Kumba mining has derived their standards:

They have a clear tree understanding the derived impact, alos when they built the core standards they tried to reduce the amount of types. We are now looking at how set up standards in a polymorphic manner that will have has many functions as needed in the base template, but the user has the ability to select the required functions, there by turning on the required capability and adding it to the template. This means as the standard evolves functions are at core, highest level, avoiding lots of different yet very similar standards. The reason for this might not initially be apparent, but as you rollout with many variations understanding the impact across sites, it will be hard if you do not control the amount of standards and variations. A basic rule should be “once something is added it should be sustained” this core principle of object orientated systems. Freedom is not always the best advantage, and putting in place a culture of someone owning the standards who then listens to the requirements and decides if that capability will be added at the highest level or what level is key. As we develop a “Corperate Standards Management” capability to ArchestrA, initially people have asked for a product, yes we will provide a capability to help manage standards across sites, but I am becoming less convinced that it should be a product vs a “Software as Service”, where the service is providing the product management skill as a service. This especially become important when you consider standards are not just automation objects or control strategies, as you move to managed operational system they will involve many types of standards, like reports, layouts, symbols, KPIS, materials, reason  codes etc.

Having one culture, one approach over all products and standards, will enable sustainability. So do companies and sites expect to have this expertise and culture, or will this “outsourced” even if the standards repository is maintained within the company, certainly we have seen this happen on some initial multi site systems.

I would be interest in your feedback.

 

Standards What do they mean?, What does it take?

As we evolve the Enterprise Control capability around multi-site and system, (yes distributed system), I have been out talking to people. A common topic is standards, the more architectures try to unify/ standardize process, operations etc., the more standards apply, but they have been round for years in control blocks. But why is it such a struggle at the supervisory level, and MES? Basically it appears to be:

·         Defining what is a standard? and Why make it a standard?

·         Governance and investment to make a standard but the much big investment to maintain and evolve the standard, it must be justified.

·         But at the core is this mis understanding that standards are like “applications”, when that are closer to “products”.

The whole concept of Enterprise Control is based on the ability to Federate and Empower Operational Workers, this can only be done if there is a consistency in operational execution, requiring standards. So we are committed to a significant investment evolving the enterprise capability especially around creating and maintaining standards.

Standards provide the advantages of:

·         Application reuse

·         Faster project time to Value

·         Reduced risk and errors

·         Reduced commissioning time

·         Provide consistency of experience, operations, control etc across applications

·         Etc

A standard is anything you want to reuse and duplicate across multiple situations. This could be symbols, documents, recipes, workflows, reports, data structures, objects, control strategies, on goes the list. But it is important to understand a STANDARD is like a PRODUCT, vs an APPLICATION, they are valuable as long as they are useful standards. As one customer said

"We are good at building standards in control, and supervisory, but useless at maintaining them so we go from one standatndard to many versions of these applocations now way to maintain."

When I quote this to many customers I get a nodd of heads, and I thought a great debate a week ago was a set of top technology executives at one company really asked the question where and what is a standard, realizing success  is based upon them, but only is if they get alignment on what they are and investment required for them to succeed.

This means standards must evolve, with new capabilities, and they will have issues so must issue tracking and fixing, so that each new version has new improvements, and fixes. This requires governance and systems to track feedback and issues against each standard, and then planning of the next versions. This is closer aligned to product governance/ lifecycle than an application/ project culture, this is probably the biggest issue we see is most companies fail to recognize the investment in governance and management of standards. This causes the standards too very quickly become un usable and not valuable, so adoption drops off.

Also the products you are applying the standards to must understand standards and templates, which a lot of tradition products do not. While ArchestrA was built on the concept of REUSE and templates, we are fully committed to evolving the standards management and governance to help sustain and evolve standards across sites/ multiple applications, and extend this capability to the other aspects of the portfolio which make up the solution. The “day in the life” in the life of standards the jobs to be done, and experience is being evolved based upon our product lifecycle experience combined with a number of customers who are apply standards, and have implemented governance.

Customers/ Sis start by building a understanding on how they will make the standards succeed, the investment in both culture/ technology and process will return significant. We hope we will continue to evolve to make this evolution to reuse of standards across enterprises a natural act. Your feedback on how you are using standards, or plans and evolution input is appreciated to tim.sowell@invensys.com.