Agile development expands into hardware world
Image credit: Getty Images
To come up with product designs more quickly and deal with rapid changes in needs, hardware designers are taking a leaf out of the software-development ‘Agile’ manual.
The story of technological innovation is littered with historic meetings. In 1874, Alexander Graham Bell met electrical designer Thomas Watson; in 1901, the Wright brothers met mechanic Charlie Taylor; and in 1970, Steve Jobs met Steve Wozniak. In February 2001, a meeting between not two or three but 17 top developers laid the foundations for a major software design revolution. At The Lodge at Snowbird ski resort in the Wasatch mountains close to Salt Lake City in Utah, they met to eat, ski and talk about the future of software design. For those in the industry, the meeting has become legendary for spawning the ‘Manifesto for Agile Software Development’.
The manifesto itself was incredibly short but it became the heart of software development for many organisations who found traditional methods no longer worked for them. Agile is not itself a methodology. It represents a different way of approaching projects: one that is designed to be better at addressing customer needs and team management.
Instead of compartmentalising the development team into groups such as quality assurance, test and programming, agile encourages members of each to work together. Engineers with different disciplines work in a small group - or scrum - on each iteration of a product design.
Typically, the team works in short bursts, often called sprints, so they can update customers on progress and get their feedback. The method prioritises software that works but does not have all the features expected from the final version. By providing customers with a minimum feature set, the team can determine whether the result of each sprint needs fixing or whether they can move onto adding more of the expected features.
Agile has proved so successful that it has not only found favour among vast swathes of the developer community but has also been appropriated, and misunderstood, by management consultants and corporate senior management in multiple sectors - a sure-fire sign of any concept’s acceptance into the mainstream.
Now, hardware engineers and product designers working with physical goods are looking at how they can adopt agile practices. Even teams working on safety-critical systems have embraced elements of agile development (‘Bug Hunt’, E&T May 2016). The question is, could a set of values that work for software design work in a setting as dissimilar as car design, for example? The answer, surprisingly, is that it’s already been tried and tested as far back as the 1980s.
“Many agile methods first came out of Japanese automotive companies,” explains Dan Hulme, senior software engineer at Cambridge Consultants, a leading UK product design and development firm. “They realised that planning everything at the start left them with no flexibility when requirements or resources changed outside of their control.”
Strategies like kanban and lean manufacturing placed strong focus on eliminating waste, creating a smooth flow of work on the factory floor, and required workers to demonstrate initiative and to take ownership of problems. “These concepts helped companies like Toyota, the exemplar of these techniques, to overtake many traditional giants of the automotive industry,” Hulme adds.
Those innovative techniques were subsequently adapted for the world of software and improved upon in the subsequent years. When it comes to designing hardware, many organisations still agree and fix product requirements early on. The design process is often rigidly structured, with clear lines of authority and development schedules laid out far in advance. For the microcontrollers and system on-chip (SoC) designs used in software-enabled hardware today the cost of a mistake can be immense. Many use nanometre-scale processes where a set of masks used to define the circuitry on the chip costs millions of dollars to make. Even a small mistake may not just result in the creation of a new set but add three months or more to the schedule.
But consumer demand is driving rapid development cycles with a growing number of products needing to incorporate embedded software to make them work. Product development now finds itself needing to make the kind of rapid headway software development made 15 years ago.
The car dashboard provides one example of the way hardware engineering is turning to agile techniques. The demand to combine entertainment and information with systems that warn drivers about problems on the road ahead has put significant emphasis on user interface (UI) design.
Like many other sectors, developing UIs for vehicles requires designing a complete, user-friendly system that incorporates many different applications. However, there are some major challenges. The first is that user interfaces must be designed in a way that minimises distraction for drivers. As such, the UI has to be intuitive and usable with minimal gestures.
Regulation can impose strict requirements on a variety of functions, for example, the time it takes for the system to boot, or certification for the software stack handling safety-critical features. In the US, a law introduced after the tragic death of a child standing behind his father’s car as it reversed demands that all cars made after May 2018 have rear-view cameras that can show a live image less than two seconds after the driver has selected reverse.
“In my car, I can hit reverse and be going somewhere before the splash screen [on the dashboard display] loads. Typically, the boot time is between four and six seconds on most SoCs,” says Johnpaul Jandu, senior marketing manager for video and displays at chipmaker Intersil. “GM has a workaround. When you touch the handle of the car, the SoC boots up. The problem is if you open the car just to grab your sunglasses, you see it boot up and show the splash screen and then shut down again.”
An alternative proposed by Intersil is to use a camera controller that, for the rear-view feature, drives the display directly, bypassing the SoC entirely. However, this type of solution may only become apparent some way into the project, once the team has determined that the boot time is an obstacle.
“Traditionally, requirements have been dealt with through a waterfall-type development model with strict specifications,” says Lars Knoll, CTO of The Qt Company, which develops a UI framework for computers and embedded devices. “However, none of the requirements would be incompatible with an agile development process; on the contrary, the development of an intuitive user interface that leads to minimal driver distraction would probably benefit greatly from a more agile approach.”
Steve Cliffe, CEO of Ultrahaptics, says his company has worked with a number of car makers to develop ways to provide some form of touch feedback for gestural interfaces. The notional advantage of using a gestural interface rather than touchscreens is that it avoids forcing the driver to look away from the road. “We have got to the point where in most cases it does not work as a standalone technology. You put your hand out to make a gesture to control something. You then want to know: ‘did that work?’ You look down and you’ve then lost the reason for using the gestures in the first place, because you’ve taken your eyes off the road.”
The idea behind the mid-air haptics technology developed by Ultrahaptics is to make it possible to feel the changes as they are made. Ultrasonic signals aimed at the skin on the user’s hand are meant to simulate the feeling of physical objects. “The knob comes to your hand. As you turn down the temperature you feel the click, click of going down a couple of degrees,” Cliffe adds.
Developing the right kind of interaction demands a great deal of prototyping, with drivers testing UIs as they are developed. “They do a lot of playing,” says Cliffe of the automotive companies. “My favourite one was a company that put it into a convertible and drove it around the test track at 260km/h to see whether they could feel it in the wind. I said I wanted his job.”
As software takes a dominant role in car functionality elsewhere, waterfall development makes less sense. Reuse of software and remote software upgrades, such as those already showcased by Tesla, will align customer expectations with that of their online habits. In this emerging landscape the car becomes a software platform with wheels, under continuous development. “We saw a similar change happen in the phone industry five to ten years ago,” observes Knoll. “I believe it is bound to happen in both the car industry and the embedded/IoT space as well.” With a stronger focus on software upgrades and delivering new functionality after the point of sale, manufacturers are likely to need more general-purpose hardware and some headroom to add these new features.
The need to make software-based systems more flexible is leading to changes in the processors themselves. For its latest generation of processor cores intended for safety-critical systems, ARM has introduced mechanisms to protect software routines from interfering with each other.
“Looking at automotive as an example, we see vehicles with up to 150 CPUs. There is a trend to consolidate and integrate those functions together,” says Phil Burr, product-marketing manager at ARM. With memory and I/O protection between software processes, “if you change some of that code you don’t need to revalidate all of it”.
Virtual and rapid prototyping techniques are proving crucial to the development of the new breed of software-embedded products. Traditionally, product development relied on an engineer’s experience to produce an initial design concept. Physical prototypes were built and tested in order to evaluate the product’s performance before typically having to be redesigned multiple times to address weaknesses revealed in testing.
Today, far more products are developed using virtual prototypes. Here, engineering simulation software is used to predict performance prior to physical construction. The engineer can test thousands of design options without the significant investments in time and money usually needed to build physical prototypes. This ability to explore a wide range of design alternatives leads to improved performance and design quality.
Physical prototyping is still invaluable and often needed to confirm assumptions and simulation results, but now takes the form of rapid prototyping, using 3D printing and a range of other increasingly cheap and democratised manufacturing methods, to iterate on aspects of the product’s usability or functionality.
In its pursuit of quieter power supplies, TDK Lambda performed both airflow simulations and prototyping. The team had end mouldings 3D-printed and fitted onto physical prototypes using different component and inlet configurations.
“We find that moving the components makes a big difference on the audible noise. Sharp edges are particularly bad,” says Paul Goodwin, product manager at TDK-Lambda.
The range of parts that can be created for prototype purposes is now vast, including a broad range of metals and plastics meaning that development of most product types can be approached this way. However, there are some exceptions: “In terms of materials that are difficult to rapidly prototype, the elastomeric and silicone materials still present a challenge,” says Mark Hester co-founder of product design engineering agency The Imagination Factory.
“Elastomeric or rubbery parts can be 3D-printed, Hester adds: “But they are very ‘chalky’ and have a low tear strength compared with their injection-moulded counterparts. The other method is to make parts using polyurethane cast into silicone tools but this is a slow and labour-intensive process that can only make 20 parts from a single tool until it breaks down.”
For all the talk of tools, it is worth remembering that agile prioritises individuals and interactions over processes and tools: “In some cases, you actually can’t do better than a really skilled craftsman,” Hester points out. “We worked on a project recently that required incredibly accurate welding and, while the company we use to do this has a host of advanced tools such as the latest laser cutters, the final weld is done by a welder with decades of experience. On that particular project we were making decisions about the design and he had a different idea, which proved to be a much better solution.” This is ‘agile’ in a nutshell: ensure there’s a development environment where knowledge flows easily so the best solutions are reached as quickly as possible.
So, do teams still need to think about ways to link long-lead-time parts of the project compared to the UI-focused parts? “That’s important however you run your project,” says Hulme. “Lots of people think agile means no planning, but it’s not like that at all. You have to start with a vision, with some idea of what you want to make. You just don’t plan in detail until the work is well-understood.”
This means that if a CAD model needs to be sent to a manufacturer a month in advance to secure the part, this gets built into the order of scheduled sprints. But the team can remain flexible about the easy-to-change parts or find backup plans that make late-stage alterations feasible.
Agile looks set to proliferate within any manufacturing and engineering company that has the sense to understand and embrace the approach properly, but a final consideration is the very word itself. Agile works, but only under the assumption of change. Change may be a characteristic of most industries - and so suits the agile approach. But if stability and reproducibility is the primary aim then ‘failing fast’ can be a very poor idea.
Managing continous integration
Agile development relies on the concept of continuous integration. The last thing you want is for additions and bugfixes from the most recent sprint to undo all the work you wanted to keep from previous sprints. The way round this is to combine new and existing code in a regression environment that reruns all the tests you had before plus any new tests defined for the latest version.
Running all the tests by hand is a punishing experience, so agile proponents came up with regression-management tools, many of which are open-source. The chip-design community has begun to embrace Jenkins and similar software to manage the test process, taking advantage of the similarity between software code and the hardware description languages they use, such as Verilog.
“Software is ahead of hardware in this area,” says Mark Olen, group manager at design-tools supplier Mentor Graphics. The firm has developed a plugin to support its own verification tools in customers’ Jenkins installations and collect data for reports on how well a project is progressing.
Because many of the tests involve lengthy simulations, Jenkins environments are now linking into cloud-software orchestration systems to find spare servers for the runs.
Standards group Accellera is working on standards to automate more of the tests - generating some of them on the fly to probe subtly different parts of each subsystem on successive runs instead of trying to make each run exhaustive.