Accelerating Control Systems Development from Research to Production - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 26:34
Loaded: 0.63%
Stream Type LIVE
Remaining Time 26:34
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 26:34

    Accelerating Control Systems Development from Research to Production

    Dr. Romain Guicherd, Dyson Technology

    Innovation is at the heart of our products at Dyson. Behind the scenes, the development journey of a product relies on multiple design iterations, each of increasing maturity. This allows us to deliver consistent improvements and to learn more about our products and systems. In the past, this development followed a document-based approach, also known as a document centric workflow.

    Embracing a Model-Based Design workflow was essential to developing ever more complex and smarter products. This workflow allows our engineering and design teams to iterate faster and to take on user feedback early in the development process, whilst delivering our groundbreaking technologies.

    Model-Based Design and simulations are the enablers that accelerate our development pace. With this workflow, documents are replaced by a collection of interlinked models. These models encapsulate both requirements and design as well as testing and reports for coverage and verification.

    Published: 4 Nov 2024

    Hello. Good morning, everyone. It's a great pleasure to be here today for the MATLAB EXPO 2024 in in this beautiful Silverstone, and to see all of you, numerous here. I'm going to speak a little bit about how we can accelerate control system development and how we do that at Dyson. We take it all the way from research to production. First of all, let me introduce myself. So my name is Roman Quiche. As David mentioned, I'm a control system engineer in the motor drives and advanced control team, and we work on power systems.

    Our team is mainly focused on designing all the control systems from our products, but we are also looking at motor design. So magnetic and electrical design of motors and control. Just a little story. I haven't been a MATLAB and Simulink user for the past 14 years, so it's been a while. I thought I would start this talk by having a little bit of a quote from James Dyson, our founder, that relates to accelerating. It's not only fitting because we are in Silverstone, one of the most famous Formula One tracks. But because as engineers, we want to be able to deliver better technology, faster to market.

    And essentially, this quote highlights the fact that solving problems and bringing innovation is something difficult. And you shouldn't give up, and keep accelerating. So who are we as a company? I think we are best defined by our products. We started as a UK-based company in the 90s, and we evolved into a global technology company today. And we design and manufacture household appliances. I think ever since we've been created as a company, we've been focused on solving problems on innovation and solving problems that impact our users.

    The very first problem we solved has been the loss of suction in vacuum cleaners and the constant need of replacing vacuum cleaner bags. So for that, we developed the dual cyclone separation system that you probably and use in your lives. And all the learnings we had about air flows at the time could be transferred to some other appliances. So I'm not going to go through them all.

    But another famous one is the Dyson Airblade, that you probably have used as well, at some point, where we use a flow of air, a fast flow of air to dry people's hands. And this is more energy efficient than using conventional warmer hand dryers or to use single use paper towels. It's a lot more sustainable than that. All those learnings have brought us to also look into purifiers and the science of filtration so we could develop purifiers. We looked into lighting, as well, to create quality light that are long lasting. More recently, we've revolutionized hair care, thanks to our small Dyson digital motors. So small, efficient, and powerful motors that could be embedded into our Dyson Supersonic, or Dyson Air apps.

    And finally, very recently, we made our first step into the world of wearables with the Dyson Zone, that you can see here, which is a purifying headphone, as well as the Dyson on track. We kept innovating all the way, developing the Dyson Airstrait, that is a straightener and hair dryer in one step. So simplifying people's life. And essentially, as you can see throughout all those products, the complexity and, as you can imagine, the control has been ever increasing, and be ever more present.

    I'll talk a little bit more about the Dyson G1 later in the talk, but that's our very first product in the wet floor care range. And the latest innovation we've made is our first step into the world of formulation with the Dyson Chitosan. Where are we located in the world? So we have multiple locations around the world, mainly in the UK. So we are in the Southwest, around the beautiful Cotswolds National Park in Hullavington and Malmesbury campus, where I work, and Bristol.

    And we have some presence in South East Asia and East Asia, with Malaysia, Singapore, the Philippines, and also some offices in Shanghai. The unique things about our offices in Asia is that we have manufacturing and R&D very close to one another, and therefore, they can influence one another. And that's kind of the key aspect of our offices over there. Just to give you a bit of a view, we have on the left of this slide, this is the Saint James power station, which is our headquarter in Singapore that we acquired in 2022.

    At the top of this slide, this is our R&D department, on the right of the top picture. So this shiny building is where all the research and new product innovation is being made. Just below is the roundhouse also on the Malmesbury site. And something unique about Dyson is that we have the Dyson Institute of Engineering and Technology. So we have students on site that work side by side with our engineers. They not only study, but also receive a salary, and they work with us, and we train them and develop their career.

    Another thing worth mentioning is the Dyson Awards. So this is all part of James Dyson's mission to bring more young minds to solve problems and innovate. And the Dyson Award is a student design competition that is running every year. We have plans for expansion. So in the next few years, we should be opening a tech campus in the Philippines, as well as a tech campus in Bristol. So those offices should be focused more on software connectivity and AI, that kind of defines our products, as we progress.

    And essentially, if we look at our products, if we look at where we are coming from and where we are going, this picture, this side by side picture, shows one of the very first product we released. So the Dyson DC01. And at the time we were mainly focused on the mechanical design of the product and the science behind the dual cyclone separation system.

    As you can see on the other picture, which is a more recent stick vac that we've released, a lot more engineering fields are being brought to life, a lot more software also. And for a product to be successful and work well, we need all those subsystem, all those fields to work together. So there is a lot of interfacing work, there is a lot of engineering and design work behind this. So how can we go faster by also having this increase in complexity? So despite the increase in complexity, we want to keep accelerating.

    This is even more the case when we look at our most complex products. So if we look at a product like the Dyson Vix Nav, which is one of our latest robots, you can see the sheer amount of technological fields that come together to make up the product. And essentially, this product, if we look at the amount of resources and time it took us to develop, it will take about 1,000 engineers a few years to bring something like that to market. So there is a real key and opportunities to accelerate things. And how can we do that, really?

    To do that, we need to understand how we work at Dyson. So we work as an R&D office with technology milestones. So each product goes through different technology milestones of increasing maturity, but each technology itself goes through technology readiness level milestones. So we increase the maturity of our technology, as well as our product. We work very closely with the researchers and the new product innovation teams within this department. So this building that you can see here, where they come up with new ideas of new products that would solve people's problems.

    And once they reach a given maturity, that is reviewed periodically, we would then transfer those product onto us in RDD, so research, design and development. And our goal, my team's goal, is to increase the maturity such that one product that works well in the lab in one, two or three rigs, we are able to manufacture this product on a large scale. So there is the challenges there.

    The important thing is that our work doesn't stop there because we have connected products, and therefore we can keep sending over-the-air updates as OTAs, keep maintaining those products and keep developing them, although they left our factories already. And another thing we work on is rolling changes. So we might have further improvements of things that are being manufactured at the moment. We are very famous for developing technology, and one of our key technology is the Dyson digital motors.

    These are key enablers of our haircare, floor care products. So they are very small, compact, power-dense motors. We developed those motors because we couldn't really find any motor that was fitting for our application. So we decided to take it upon ourselves and recreate a motor that would work. And doing that enables us to have a motor that is really fitting and tailored to the application we want to develop. So every time we would have a motor perfectly tailored for the product.

    Motors are very interesting because there are a lot of technological fields around them. My team is mainly focused on the magnetic, the electronic, and the control side of the motor. But we also work closely with people looking at thermals, at mechanical, as well as aero and acoustic. To give you an order of magnitude, if you've never seen our DDM, or Dyson Digital Motors, they are very tiny. You can hold them in your hand. They are about 200 grams, but they develop just under 1 kilowatt. So it's a fairly compact package for a lot of energy.

    Recently, we've been doing a lot of work with MathWorks to optimize those motors and essentially accelerate the development. So that's part of the work we've been conducting recently through something we call the simulation framework, where we can manage a lot of simulations efficiently with pre-processing steps, post-processing steps, and run very large batches of simulation. The idea is that we can sweep a lot of design parameters and converge towards an optimal design.

    When I say optimal design, I mean something that is more energy efficient, but also looking at metrics like manufacturing. We want something that is a little bit easier to manufacture and that creates a better yield when we manufacture those motors on a very large scale as well. We've worked further to make this framework available in the company, so we've packaged it. We can maintain it, either internally, or with the support of MathWorks, again. And this is something that we keep developing.

    We not only work on technologies, we also work on products. So I'm going to play now the Dyson Wash G1 engineering video. For a little anecdote, today is exactly the one year anniversary of the Wash G1. We released it last year in China. And here you go.

    There's an increasing prevalence of hard flaws within our homes globally. We identified the need to design a machine that could not only pick up dry dust in debris, but also collect stains and spills that we find in places like our kitchens and bathrooms.

    The challenge with Wash G1 was, we're doing this for the first time and we're trying to understand cleaning performance. And the only way for us to do this is to physically make machines, and test them, and improve, and test again.

    When we were testing with wet vacuums that use suction power, we found that they may expel unpleasant odors from the vacuum exhaust.

    So the design of Wash G1 doesn't rely on suction. Instead, we developed a new system, using two counter-rotating rollers.

    We developed a microfiber material with 64,800 filaments per centimeter squared. This extra high density microfiber is great for good cleaning performance. The Dyson Wash G1 also has three user selectable hydration modes that enables you to select a hydration level that is ideally suited to the type of flooring in your home. There's also a max mode, which maximizes the flow of water to the rollers to remove stubborn stains from the floor.

    We hydrate the counter-rotating microfiber rollers at 13 points along each roller. These secondary rollers with nylon bristles strip the large dirt and debris from that roller and collect it in the debris tray. There's one more crucial step, which is our rigid extraction edge that presses into the microfiber, extracting the dirty water and enabling us to collect it in the dirty water tank.

    So the collection of the dirty water and debris will all come within this tray. And there's a fine mesh inside of here that's 500 microns. And the reason for that is to separate the solid debris from the liquid. And then, when it comes to disposal, you can pour the liquid straight down the sink, and then the tray will collect the large solid debris, which makes it much easier for you to go and empty that out, much more hygienic.

    We went to great efforts to design all the parts, to enable them to be really easily cleaned with the wipe of a cloth. We wanted to make sure there were no tight corners or edges where dirt and debris could accumulate.

    At the end of your cleaning, you can put the machine through a self-clean mode, where it's just purging through all the tubes, rinsing off the rollers, rinsing out the debris tray, and it just gives a bit of a deeper clean of the machine before you start your next clean.

    [MUSIC PLAYING]

    So I've been speaking about simulation for DDM. But there is another thing that makes us accelerate our engineering development and releases, and this is essentially the model-based design workflow, as you've heard already this morning. This product was the very first one that we did in this weight flow range, and therefore, that was quite a good project pilot project to try and push our model-based design development. So any good model-based design development should start from the requirement level. We work with design manager and program manager that will come up with the product vision. And we start from the product top of our requirements.

    As engineers, we can refine those requirements into subsystem requirements that we can then implement. And more and more, we've been using the Simulink requirement manager to have a view of the requirements and the implementation side by side. But it goes beyond that, because we can also link requirements to implementation and see how one requirement is implemented and understand the trade offs we've been taking.

    The other thing that this enables is that we can track all the implementation progress, and talk to the program manager, and explain what we can deliver when, and therefore, work on planning, and go faster through solid planning. The last key point that was very important to us is, understand the impact of changes. So very often because our products are evolving, some requirements will change. So what happens if we change one requirement? We can understand the impact on the implementation.

    And similarly, if we need to change something in the implementation, what is the impact on our requirements set? So that was really key. And more and more, we are trying to push the user of the product manager to embed requirements directly in the tool. Our requirements, at the moment, are more done externally and we offer them. But more and more we are trying to work with teams that would give those requirements to us where we can import them in the tool.

    So once we have requirements in a clear product vision, the next step is really to start modeling the different subsystem of the product. If I take the example of the Dyson Wash G1, we looked at modeling the battery pack. In this case, we had a four-cell battery pack. So we collaborated with our sales team, with our battery management software team, to understand how we could model the battery pack using Simscape Electrical, Simscape thermal. We collaborated with our hardware electronics team to model all the motor drives and electrical harnessing, and that's done also through Simscape Electrical.

    So these are first principle modeling, making sure the behaviors we observe on the rigs are exactly the same as the one we see in simulation. And finally, we collaborated with our motors and different pumps on the product. We had a water pump and an air pump. So our motors and pumps team were defining the behavior of the pump, and we used that to model them for that example for the motors. So there are two motors for the foam roller motors. We looked at dyno data, so we did not only first principle modeling, but we looked at generating data in the dyno and comparing the data we send the dyno to our models, making sure everything was in line.

    And finally, we modeled the mechanical system, as well as the floor interaction. So that's how we managed to model the entire system. The beauty and the power of that is that it forces us to understand the system inside out, and we can then start seeing trade-offs. So what happens, for example, in this example, if we start speeding up rollers a little bit faster? What is the impact on runtime of the product? But what is the impact on cooling, as well, of the motor, and therefore, on the reliability?

    So we can state that moving a parameter essentially has an impact on all the other parameters of the system. And this allows us to provide the trade-offs. Another key point is that having a full digital twin of the product enables us to do the control design. And that's what we use to design all the control systems of the actuators. So what we did is starting to put all those requirements together and see what building blocks were coming through.

    And then, using some strict modeling standards, we could develop the control system model for the formula motors. So one thing that happened when my team was tasked with this work a couple of years ago, is that it-- I think it enabled more team collaboration. Because it's such a visual tool that we could explain to people how the control system works without them having to look at a page of C code. And that was really powerful to make the project go faster.

    The other thing that was also quite beneficial is that we could architecture it quite clearly and understand that each block has a particular function with different level of understanding, as you might have seen in Simulink. The team collaboration was enhanced from-- on the outside. So when we were talking to people outside, such as design manager and program managers, but also inside the team. Because we could break down the entire control system into chunks that one engineer could design and then bring them together, kind of creating work lines in parallel.

    Something that I would always remember is how we could do rapid control prototyping. I remember doing some modification in the morning on the model, generating the code, flushing it onto a rig in the afternoon, and seeing the code I had done in the morning, just running the same way as my Simulink model. For me, that was another powerful aspect of that model.

    And finally, throughout this work, we also realized that we were using a lot of blocks over and over, and some functional blocks that we created. And we could kind see that there were a platforming idea, and we would reuse those blocks over and over onto other projects. So we started to look at creating our own Simulink libraries and share them in the company so that we can reuse and go faster on future projects.

    And for all of that, we used Simulink Embedded Coder. Finally, we wanted to increase the quality of our deliveries. So we invested a bit of time and effort into testing our model. As you can see here, it's the same model as before in a test harness. So we've done linking the model to requirements, also linking our test requirements, and be able to understand what we test in the model.

    Looking at tests, such as model in the loop test, software in the loop test, and processor in the loop test, as you're probably familiar with, that would guarantee that every time we send a delivery out there to another team for integration, this team would pick up a delivery that they are confident in and there are no defects. So I can quote some of our software engineer that mentioned that the Wash G1 development was virtually bug-free, and we didn't see any issue of generating codes.

    We also use coverage to understand what is covered, and if we need to either clean up the model, or build more tests. So how did we deliver the Wash G1? If we-- I looked through our line of delivery that I plotted on a timeline, and we essentially adopted a new philosophy which is small, frequent, incremental release. So release early, release often. That enables us to be really adaptable to changes. So any change can be tackled very quickly, and the code can then be integrated by our embedded software team.

    If we look at the number here, we did 75 releases. So from January 2022 to November 2023. And if you look at the average, it's about one release every nine days. So it's really relentless development. Kind of reflecting back on our journey, I think the Wash G1 was a good opportunity to do model based design, because it was the very first product into that range. And at the time, we had a very good team knowledge built around model based design. So if we look at previous projects, what we did before was more document-centric. We would follow this linear workflow, where we would have-- we would still use models, so we would use a model to develop the control system.

    But this model was then used to write requirements and understand what the control system had to do. Then, we would pass this document on to the next team that would then write the embedded C code, and this would then make it all the way to production. It was quite a linear process, prone to error, because you could interpret documents wrongly and make mistakes there, and you have extra steps that are not automated or that are a bit tedious.

    With model-based design, the model is at the center. So we mainly work on a collection of model, a model for requirement, a model for a test, a model for the actual implementation, and everything is interlinked. So from this model, we can generate the code, generate the documentation. We don't have to rewrite the documentation. So we cut through a lot of steps, saving a lot of time, as well, and making it more robust, having less error possible.

    So that was a journey with the Wash G1. I think, reflecting on it, more, and how you can bring the same journey in your company, I think one of the key things was to bring it step by step. Not to go the whole way in one step. So you have to think of how can you use model, first of all, to generate code, potentially to just do testing and rapid control prototyping, and eventually how can you bring this code to production? Potentially, how can you certify this code, as well, using some of the IC tool boxes?

    So the key advice is, incremental-- the same as for release, frequent incremental deliveries. We have to do step by step adoption of model-based design. So in summary, how did we accelerate control system development within Dyson? I think there are two key elements. The first one is harnessing simulation, doing more simulation to have less prototypes, and do prototypes only at key steps in the development. That's the first point.

    The second point is work on the workflows. So using model-based design to improve the workflow and improve the speed of the workflows. So yeah, these are the two key steps. Finally, where are we going next? So we are not done yet. Obviously, we want to bring more simulation, and we see more teams, little by little, doing simulation in the company. Initially, we were building all our models, but more and more we see teams creating their models and passing it on to us, and we play the role of integrators.

    So we would work with the thermal team that would create a thermal model, pass it on to our team, and we can integrate it and design the control around it. And we see also that more simulation is guiding the design of products and the development. Finally, we also want to spend more time doing reinforcing our model-based design, strengthening our model-based design workflows in the company.

    We started training more engineers with the help of MathWorks. So if you have this opportunity, give them a call. They will be happy to help you to set up your model-based design workflows. Training more engineers, showing them the benefits. I remember, at the very beginning, when I was talking about using model-based design to generate code, or embedded software, engineers were not really sold on the point, but now, today, they are asking for it. They are asking us to do more model-based design, development, and control.

    And finally, our last point is the increase of automation. So how can we gain more time? Increasing automation using continuous integration, or continuous integration and continuous development, is another key aspect of accelerating development. So our next plan is to integrate the CI process into our bamboo pipelines. Thank you very much for your time. I hope you find this insightful.

    [APPLAUSE]

    View more related videos