Smart products and devices tend to be very complex. Customers demand products whose functionality is just right for them. They also want products that look good and demonstrate their individual values. That often means creating a product that the customer can customize. This wide scope of possibilities causes complexity. There are many requirements, and it's difficult to envision all use cases. The implementation of such a product that fits the requirements at a competitive price involves more engineering disciplines and specialities than dumb products. Finally, product testing and verification is challenging.
In the Victorian era, a product was often created by an individual inventor. Those days are long gone, and products have steadily grown in complexity. Smart products and devices represent a step change in complexity.
In the 1960s and 1970s, engineering management popularized the idea that design projects could have better outcomes if they were tackled by multi-disciplinary teams. References to this approach date back to the 1920s, when it was realized that organizing into departments and firms, each of them specializing in a particular expertise, tends to create barriers. Assembling a single team of individuals with all the necessary expertise produces a more innovative approach to solving design problems. The common purpose focuses effort on the project outcome and discourages suboptimization.
In the past 10 years, smart products and devices have added a new discipline to the mix: software engineering. That adds complexity and new modes of thought from the world of software development. In the short term, it creates some communication difficulties, especially when the software people come from a pure computer science background. However, we should also see this as an opportunity. Different engineering disciplines can learn best-practices from one another.
The world of software development has learned how to cope with rapid change in requirements and underlying technologies. As well as the traditional waterfall development model, a technique called agile software development has emerged. In this approach, requirements and solutions evolve through collaboration between self-organizing multi-disciplinary teams. The software development is iterative. Incremental solutions are released to users, who provide feedback and help develop requirements for the next iteration.
This technique could sometimes be applied to other engineering disciplines. The prerequisite is that different disciplines use a common language for requirements (especially derived requirements) and solutions.
Systems engineering and systems modeling allow better communication of a solution's architecture to the requirements by dividing the solution into manageable chunks. Simulation and visualization of solutions allow each discipline to communicate its solution to its peers.
The main mechanical engineering software suppliers are expanding their portfolios to include systems and software engineering tools. Dassault bought Geensoft, PTC acquired MKS, and Siemens PLM bought LMS. These tool sets are evolving rapidly. There are potential problems with agile development techniques. How do you test for safety when a product is used outside the use cases in the requirements? If the solution iteration triggers a change in a mechanical or electrical artefact, then costs can increase dramatically.
We do expect all these software engineering techniques to change the design workflow. There are things software engineers could learn from mechanical engineers, such as using more off-the-shelf components, rather than writing all code in-house from scratch.
We will be watching with interest this first encounter with alien software engineers to identify best-practices in the design workflow.
Mike Evans is the research director for Cambashi.