By Daniel Dearwater, PAS’ Global Invensys Channel Manager
/blogs/airbus.aspx)
As I get started here with the 4th installment I am reminded of a sobering fact; I’m
BEHIND IN MY BLOG GOAL and really should be writing my 6th or 7th entry, so it feels very good to be writing. Coupled with that, as I’m writing this blog I’m taking my first ride on an
Airbus A380 aircraft from London to Dubai; it seat’s over 800 people. WOW! I’m not usually impressed with aircraft too much, however as an engineer I can’t help but marvel the achievement of this vehicle… but I digress. Let’s get keep exploring the future of DCS migration projects.
So let’s fast forward to where the automation work begins. The FEED has been completed, the process documented, and now the Main Automation Contractor (who I will call MAC) has to deliver against that design. This entails migrating existing strategies, HMIs, and alarm systems, while reengineering where appropriate to bring these new systems into more modern hardware to ensure sustainability. Well that’s no big deal because MAC is engineering with Integrity! Not only does MAC know exactly what to do, but he can do it better than before while ensuring that the accumulated garbage doesn’t make its way into the new system. So you could say, MAC + Integrity = MAC Daddy. I know what you’re thinking…
”We already covered this didn’t we? I know Integrity really helps up front on DCS migrations but how is it supposed to add value during the build phase?”
Well, hold your horses, I was just about to tell you. In a nutshell, Integrity enables a higher level of delivered quality given the same project schedule and reduces schedule risks associated with common potential project delays to ensure on-time delivery. How is this done you ask?
By enabling better engineering utilization through Integrity™, specifically:
- Continuous Automation Validation of design against as built configuration
- Continuous configuration error identification
MAC has processes in place to validate design and detect configuration errors. In most cases, validation and defect identification is during FAT.
WHAT?!? It’s unbelievable that we’re depending on a small handful of engineers working incredibly long hours to catch every potential error from a design, process, and system configuration standpoint.
Do you think all errors are caught with today’s FAT process? I seriously doubt it.
This leaves a big potential for schedule slip or showing up to FAT with a system not ready for prime time. Also since MAC is documenting the system as it’s being built, with
Integrity™, some MACs I know have an advantage! Let me explain…
Since, validation and configuration defect detection can now be done
continuously due to auto updating, as-built documentation, and key Integrity™ software features, MAC can ensure that this process is done continuously during build process and not during FAT as a crazed last minute intense effort to get everything passed.
/blogs/mac_daddy.aspx)
That atmosphere encourages human error and since we are using
Integrity™ software to compare and expose defects, the chances of certain mistakes making it to FAT are almost non-existent!!! This is good for MAC and very good for the end user because quality has gone up and schedule risks have gone down due to reducing the unknowns.
So, for those out there in the middle of a migration, with so much cost tied to a successful FAT; do you just want a MAC or
MAC Daddy?
I hope it’s the latter.
In any case, I think this is a good place to leave you. As always I’ll give you a peak at what’s up for the next few installments for
The Most Competitive DCS Migration: global engineering collaboration, a better FAT/SAT experience, and the project documentation of the future.
Thanks for reading and see you again soon.
22 Blogs and 265 days remaining…