1661880454117 1opafpanelarticle3

ExxonMobil takes IJH challenge to new level

Oct. 24, 2019
The company's senior technical professional, upstream, Erik Bruyn showcased its initiative to reengineer the control system, known internally as It Just Happens.

“We do the full project—design, philosophy—all the steps, every time. Why? It’s like when we used to assemble our own computers in the 1990s.” ExxonMobil’s Erik Bruyn discussed the company’s next set of challenges for the automation supplier community.

With the widespread adoption of configurable I/O and recent introduction of intelligent enclosure modular junction boxes, it’s time to move on to the next steps for streamlining the process of engineering, installing and maintaining industrial control systems.

“The smart junction box has improved our work efficiencies,” said Erik Bruyn, senior technical professional, upstream, ExxonMobil. Started as a challenge to suppliers to get automation off the project critical path by separating engineering and deployment, “We now have five years of experience with these junction boxes, and they work. But the world changes. How can we improve on it? And not just incrementally.”

Bruyn presented “Project engineering, design and implementation” at Schneider Electric Innovation Days this week in Austin, Texas.

It just happens 2.0

ExxonMobil’s initiative to reengineer the control system, known internally as It Just Happens (IJH), is driven by simple principles: to reduce the complexities and risks of upgrade projects; to eliminate or reduce manual steps, dependencies, customization and duplication of work; and to include cybersecurity, data handling and networking by default. IJH 1.0 covered the smart junction box, and IJH 2.0, intended for completion by 2021, seeks to define the modularized functional container for software, the smart standard controller, and a standard, integrated engineering tool.

Today, “It’s not an easy task to do an upgrade, it’s pretty complex,” Bruyn said. Systems have been designed over time in a very integrated way—separate hardware, software and operating systems made to work together, but not made to be upgraded.

When an upgrade is made, “We do the full project—design, philosophy—all the steps, every time. Why?” Bruyn asked. “It’s like when we used to assemble our own computers in the 1990s. Today, we’re also adding cyber on top, and yet another threat means another solution.”

Instead, “Consider the smart phone,” Bruyn said. “It’s very different. You can change the phone and keep the apps with all your data. How can we do our systems more efficiently? Can we apply standards in other parts of the system?

“We need to rethink, challenge and find a way that’s not just a little, but much more efficient, like the junction boxes, where the time to commission a loop has gone from an hour to five minutes. We need to challenge every piece, look at the whole workflow. And not just get a 10% improvement, but at least a 60-70% improvement.”

Modularized functional container

IJH 2.0 envisions a modularized functional container for software connected to an asset, with control, alarms and cybersecurity built in, and including functionality for startups and shutdowns. “Eighty to 90% of the software stays the same, so why re-engineer it?” Bruyn said. “And let’s make it independent of the hardware.

“We want to build in modules, and make the software in modules,” Bruyn said. “These should be configurable, but not with 200-plus parameters, just the needed choices to suit the specific equipment.” For example, on a separator, “How many variations do you really have? It’s not really proprietary stuff anymore,” he said. “You should be able to order a pre-engineered module, and configure what you want.”

The same applies to graphics. “Traditionally, these have been customized because the operator wants this or that, so different plants have different graphics,” Bruyn said. “Then, any upgrade involves a graphics update.”

Finally, “Cybersecurity should be built in,” Bruyn said. “The modules should have the cyber they need for access, intrusion detection, etc. It should be configurable, but there by default, and built in.”

Smart standard controller

“We must consider at every step—do we need it? Can we simplify it? Can we automate it?” Bruyn continued. “A controller is still a big, customized box. Why not make it a part number, plug it into the network preconfigured with cyber, and use it to run functional containers? Spec the functionality, and let the vendors determine the technology.”

ITH 2.0 seeks a smart, standard controller that would have an industry-standard, real-time abstraction layer; be auto-binding; run third-party, vendor-agnostic applications; and come in standard enclosures.

Standard, integrated engineering tool

“Why not have a single engineering tool from the beginning through the lifecycle?” Bruyn asked. “Why are we redlining drawings and updating them? Why isn’t the system self-documenting in an integrated tool that does all that?”

IJH 2.0 calls for a virtualized engineering tool for all automation that supports visualization, simulation, testing, and automated build of functional containers. It would be self-documenting, and come with a smart data interface and a library of prefabricated functional containers.

“What would this give us?” Bruyn said. “We’d get a major step, at least 30-60%, in capital efficiency.” Functional efficiency also improves with uniform quality of software across units, and alarms and graphics that are “best-in-class, which is good for operations,” he said.

“Why do we put up with 10,000 alarms on startup? Because when we put all the components together, we had enough to do, and we didn’t think about alarms,” Bruyn said. “Instead, we can do them upfront in the functional container, for the equipment type of the module. We’ll also get quality data, available for analysis, the cloud and workflow, and simplified, agile, high-value app deployment. And it’s open, so we can run any app from any vendor, with built-in cyber.”