A couple of weeks ago I talked about the 3rd
generation 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”?
No comments:
Post a Comment