Digital Solutions for Downhole Product Development | MathWorks Energy Conference 2022 - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 8:41
Loaded: 1.89%
Stream Type LIVE
Remaining Time 8:41
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 8:41

    Digital Solutions for Downhole Product Development | MathWorks Energy Conference 2022

    From the series: MathWorks Energy Conference 2022

    Will Thompson, SLB

    Schlumberger has a history of delivering advanced digital solutions throughout its key business and product lines. As part of its digital transformation journey, SLB is taking a holistic approach to the development of advanced digital solutions for end-to-end workflows in core and future energy technology solutions. In SLB’s core service downhole domain, it has been transitioning to modern platforms for embedded software development. This creates a complete lifecycle ecosystem that allows SLB to rapidly develop new digital solutions of the highest quality possible.

    SLB uses MATLAB® and Simulink® as its primary modeling environment for system modeling, algorithm design, and model-based software development. This presentation will review some of SLB’s business drivers, challenges, and specifically, how SLB has worked with MathWorks Consulting Services to address these needs in the modeling domain.

    Published: 20 Mar 2023

    Hello, everyone. I'm Will Thomson, a software program manager at SLB. In my current role, I oversee embedded software development of downhole software products in both well construction and reservoir performance. I have been working with SLB in digital roles since 2011, starting as an embedded software engineer for downhole tools, before moving onto the creation of automated test systems to validate downhole software, including hardware and modeling the loop testing methodologies. I then took up several management roles, overseeing the full development cycle of embedded software, surface software, and automated test systems.

    Today, I want to discuss SLB's focus on digital advancement of our downhole systems, specifically the product lines that I am involved with, and the applicability to other areas of our business. In the rapidly evolving energy market, we are challenged to deliver products more rapidly with an ever expanding set of capabilities.

    There has been an increased demand and value in delivering customized assets to specific customers and geographies. Like in many other industries outside of energy, there is an increasing trend in delivering product improvements and enhancements through software feature releases.

    This greatly increases the complexity of managing and testing each release of software against our hardware platforms to ensure we are delivering on time with highest first article quality possible. During the work I do, I am often reminded of the excellence in execution, doing the job right first time every time, internal campaign when I joined SLB.

    In today's world, we have become overly accepting of software defects and failures in our day to day lives, where we are quick to try turning our devices off and on again when we encounter issues. And if that works, we continue without giving it a second thought.

    Software and embedded software are prevalent and nearly all that we do, from making our coffee, cooking our dinner, and driving to work. As an embedded software engineer by training, I sometimes stop and think why the device I'm currently using even require such complex embedded software routines. Something as simple as the extractor fan above our cooker is now a fully software enabled device with complex logic around heat management and forced fan control, if we turn it off too early.

    Often, devices such as these in our home and everyday life have little hiccups, and we simply turn them off and on again and think no more of it. The reality, however, of a lot of our SLB downhole products today and their ever increasing digitization is that if they were to stop working we cannot so easily turn them off and on again. This is much more than a minor delay or temporary annoyance.

    If you attended the talk last year at the conference, which was given by ExxonMobil, they concisely showed how we can easily get into a situation in oil and gas offshore where a million dollar a day rig rate is on the line should the situation arise where we have a failure. This illustrates very well that in our industry the cost of failure is very high, and that all efforts need to be taken to prevent unnecessary non-productive time.

    In SLB, to achieve this in the portfolio I am responsible for, we are constantly modernizing our embedded software development practices and platforms, developing techniques such as left shift testing, where we move continuous testing earlier in the development process, automating it, and ultimately increasing the frequency and coverage of testing to capture issues long before deployment in the field, focusing on optimizing our DevOps implementations to make the interactions of our planning, developing, testing, deployment, and operational parts of the system seamless wherever possible.

    Behavioral modeling has been part of our development process for years, in the experimentation, design, creation, and test of our products and software. As the field of modeling is so broad, I wanted to briefly illustrate what I mean by behavioral modeling. In the context of embedded software development, we are talking about controller and plant models simulating the product or the product's operating environment.

    Traditionally, this modeling was primarily in the experimentation and design stages, allowing our physicists and control engineers to rapidly develop their ideas and evaluate what would work in engineering development of our products. This initial phase of modeling work would, in the past, allow the creation of a software specification and set of requirements that would allow our software engineers to then create the embedded software and test cases against these documents.

    The MathWorks suite of software has some extremely useful features that allow these models values to be increased, whether through test harnessing to define model level tests to exercise more fully the conditions the model and end system must handle, or even tools to convert models into real-time executable C and C++ code modules.

    Although it is easy to talk about doing these things, the reality of being able to do so is very different, of which I am sure a few of you are familiar. Initially, we had self driven learning and natural adoption of these techniques taking place in silos around the organization, although as use increased it became necessary to try and adopt some best practices around structure and model management, so we organized several classes from MathWorks that are locations for key users.

    Alongside the MathWorks training, we started to use MathWorks consultancy services for some key projects to help with technological or integration issues between our models and our hardware development and testing environments. These engagements were highly effective in tackling specific areas of interest.

    While this worked well for the specific projects involved, it was not a sustainable or cost effective way to scale up and truly realize the complete benefits of behavioral modeling throughout the product lifecycle of our critical products. To help us move towards our end goals of having efficient fit for purpose behavioral models driving the development and testing of our embedded software, we decided to approach the MathWorks consultancy team more broadly and invited them to do an assessment of our current modeling capabilities and how effectively we were using their tools across our organization.

    This assessment delivered a report of our current state and an outline of suggested key areas of focus to move forwards, whilst increasing efficiency and adoption wider in our company. Concrete steps we have taken since the assessment with the support and continued involvement from MathWorks is a set of common model development quantity criteria, with several project templates for plant and control models with automated compliance checking, a central model repository for behavioral models to be reused and shared across SLB, with each model within being checked against the established criteria and automatically assessed to be in the correct structure for reuse or not.

    Establishing a forum for the community of modelers across the company to interact and feedback on the automation and tooling put in place. And most importantly, in my opinion, was the creation of a central team with support from our leadership to manage and advocate for the adoption of these modeling practices.

    We are confident we have put in place a sustainable infrastructure that we can continue to improve year on year in an agile and iterative manner to drive efficiency, quality, and faster delivery of our products reliant on embedded software, not just in our extensive oil and gas-centric portfolio, but increasingly in our new energy and sustainability emerging technologies.

    Thank you for your time. If you want to learn more about SLB, please visit our website at slb.com