Dyson Accelerates New Product Development with System-Level Simulation
Model-Based Design Used to Develop a First-Generation Product
Dyson’s research found that a new approach was required for the best wet cleaning solution. This led to the Dyson Wash G1, which reimagines a household staple that can trace its ancestry back centuries—the mop.
For this latest feat, Dyson engineers borrowed from engineering methods for complex systems in other industries, such as aerospace, to design an everyday product. Dyson’s document-based workflow, which worked well for developing new versions of existing products, wasn’t the best fit for creating a new product line. Instead, Romain Guicherd, lead advanced control systems engineer at Dyson, convinced his team to try Model-Based Design. Model-Based Design uses system-level simulation models to improve how engineered systems are developed.
“It allowed us to speed up the development workflow and deliver a more robust code for testing,” says Guicherd.
First-Generation Product
When designing a new version of an existing product, such as a vacuum cleaner, Dyson uses a written, document-based approach to pass requirements from one team to the next during the development process. This approach works well for established products, as engineers can refer to and iterate on past designs and embedded software. However, this process of document handoffs could muddle the development of a brand-new product line.
The Dyson Wash G1. (Image credit: Dyson)
“With a written design specification, other engineers may interpret requirements differently,” says Guicherd. “Developing a new product line was an opportunity for us to investigate a new way of working that would reduce the opportunity of miscommunications between teams and ensure a smoother collaborative process.”
A Rough Road to a Smooth Process
Dyson saw Model-Based Design as the process that would allow them to explore innovative capabilities.
“We needed to explore many different concepts and directions,” says Guicherd. “Using Model-Based Design and Simulink models gave us the ability to be agile and turn new ideas around twice as fast compared to our document-based development process.”
“Using Model-Based Design and Simulink models gave us the ability to be agile and turn new ideas around twice as fast compared to our document-based development process.”
The winning cleaning concept for the Wash G1 incorporates a cleaning head with counter-rotating rollers covered in a dense microfiber cloth. To separate wet and dry debris, Wash G1 uses a set of secondary rollers that catch all the solid debris in a tray. A mesh filter lines the bottom of the tray, allowing the liquid to pass through into the dirty water tank. To make all of this happen and deal with all potential situations, Guicherd’s team needed tools that would facilitate the simulation of the interacting system elements and support everything from design to code generation and software testing.
To develop the controls for the cleaning rollers, the team modeled the foam roller motors and motor drives using Simscape Electrical™. They used Stateflow® to design the scheduling and controls for the cleaner’s two pumps—one for hydrating the rollers with clean water and another for extracting the dirty water. Stateflow was also used to implement the self-cleaning mechanism on the product.
Components of Dyson roller technology. (Image credit: Dyson)
Components of Dyson roller technology. (Image credit: Dyson)
Components of Dyson roller technology. (Image credit: Dyson)
Components of Dyson roller technology. (Image credit: Dyson)
The Wash G1’s cleaning performance required multiple selectable hydration levels, each with fine-tunable sensitivity levels. These different settings and variations in cleaning loads all demanded accurate voltage control.
“We used our Simulink models to adjust parameters and test different values to fine-tune and develop the motor voltage control faster,” says Guicherd. “The simulations helped us understand the effects of the design changes without building a physical prototype.”
Dyson roller technology modeled in Simscape. (Image credit: Dyson)
The team used Requirements Toolbox™ to link their requirements to their Simulink® model, which helps show how a requirement drives product features. “Before using Requirements Toolbox, we would not know if a requirement was wrong until we reached the hardware testing stage,” says Guicherd. “By connecting requirements to the model, we understand how each requirement is implemented and the relationships between them.”
Benefits of System Simulation for Design
Model-Based Design with Simulink and Simscape™ facilitated a more systematic approach and let Dyson conduct various types of in-the-loop testing before building and testing the prototype. With Model-Based Design, engineers could perform multidomain modeling and collaborate with other teams. For example, Guicherd’s team created an accurate four-cell battery pack model with data from the cells and battery management systems team. Working with the electronics team, Guicherd’s group used Simscape Electrical to model and simulate the behavior of the power electronics hardware.
“Using system-level simulation with Simulink gave us the ability to consider more design options and compare tradeoffs, so we spent more time in the design phase of the project. The benefit of that was that we found design errors and integration issues when they were easier and less expensive to correct.”
“Using system-level simulation with Simulink gave us the ability to consider more design options and compare tradeoffs, so we spent more time in the design phase of the project,” says Guicherd. “The benefit of that was that we found design errors and integration issues when they were easier and less expensive to correct.”
From Software Architecture to Embedded Code
In a subsequent project, the team added System Composer™ to develop the software architecture. Guicherd says, “With System Composer, the product and software teams worked together to develop the software interfaces and scheduling and to model different scenarios.” System Composer allowed the team to organize large models into logical groupings, enabling team collaboration while avoiding merge conflicts.
"Using rapid control prototyping, we could quickly generate code and, by the next day, show them how the product behaves in the lab.”
The Simulink model provided a visual description of the product behavior, which also enhanced collaboration among the team members throughout the development process. C code was generated from these control system models. “We would adjust the model, comment out some parts, add some new blocks, and show the software engineers the new behaviors of the cleaner. Using rapid control prototyping, we could quickly generate code and, by the next day, show them how the product behaves in the lab,” says Guicherd.
Instead of coding manually, the team used Embedded Coder® to generate C code from their Simulink models. The software team then incorporated that into the main code base for the machine’s NXP™ microcontroller. “With Embedded Coder, we could do a software release every nine days,” says Guicherd. “Before, when we manually coded, it was about once every 10 weeks.”
“Initially, we focused more on making it work in the lab, so the model and generated code were the key bits. But very quickly, we realized that the model, plus the code, tests, and coverage, were making our product even better,” says Guicherd.
Testing to Perfection
The team devoted more time to refining the design than was typical with previous products. With Simulink, they could quickly address errors that came up during simulations, which paid off during testing. The phase was far simpler and quicker than in the past, saving the team development time and effort.
“With Embedded Coder, we could do a software release every nine days. Before, when we manually coded, it was about once every 10 weeks.”
“Once you design something in the model and it works, you put it in a product, and it works exactly as the model does. Testing was quite simple in that sense,” says Guicherd. “It allowed for a zero-defect delivery.”
The success of Model-Based Design and code generation for the Wash G1 erased initial skepticism from the software team. Once wary about the generated code’s ability to adhere to the internal standards and maintain execution efficiency, they have developed confidence in the code. The software team now partners with the hardware team to define the API for the generated code. Using Simulink for Model-Based Design offered them both flexibility and greater speed.
“Now, they’re the first ones to ask us to do it again and ask if we can use this process for another product,” Guicherd says. “As the project’s complexity increases, they see the benefit of Model-Based Design.”
Dyson WashG1 mop testing. (Video credit: Dyson)
For future iterations of the Wash G1, the Dyson team can reuse elements of their model, and their example of design methodology using Model-Based Design is gaining traction in other departments—for instance, Guicherd says teams are considering its use in hair care products and other aspects of floor care, paving the way for even more innovations across Dyson’s products.
