Business initiatives that respond to consumer and business demand for smart products and devices.
Smart products and devices tend to be very complex. Customers demand products that have functionality just right for them. They also want a product that looks good and demonstrates to others their individual values. That often means creating a product that can be customized by the customer. This wide scope of possibilities causes complexity. The requirements are wide in scope and it’s difficult to envision all usage cases. The implementation of a product that fits requirements at a competitive price involves more engineering disciplines and specialities than “dumb” products. Finally, product test and verification is challenging.
In the Victorian era, the 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 1960’s and 1970’s, engineering management popularized the idea that design projects can have better outcomes if they are tackled by a multi-disciplinary team. There are references to this approach in the 1920s when it was realized that organizing into departments and firms that specialize in a particular expertise tends to create barriers. A single team comprised of individuals with the necessary expertise produces a more innovative approach to solving design problems. The common purpose focuses effort on the project outcome and discourages sub-optimization.
In the past ten years, smart products and devices have added a new engineering discipline – software engineering – to the mix. That adds complexity and introduces new modes of thought from the world of software development. In the short term, this creates some communication difficulties, especially when the software people come from a pure computer science background. However, we also see this as an opportunity. Different engineering disciplines can learn best practices from each other.
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 emerged called Agile software development. In this approach, requirements and solutions evolve through collaboration between self-organizing multi-discipline 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 communications language for requirements, especially derived requirements, and their solutions.
Systems engineering and systems modelling allow better communication of the architecture of a solution to the requirements by dividing the solution into manageable chunks. Simulation and visualisation of solutions allows each discipline to communicate its solution to its peers.
The main mechanical engineering software tool suppliers are expanding their portfolios to include systems and software engineering tools. Dassault bought Geensoft; PTC acquired MKS; and Siemens PLM bought LMS. These tools sets are evolving rapidly. There are potential problems with agile development techniques. How do you test for safety when a product usage is outside the usage cases in the requirements? If the solution iteration triggers a change in an existing mechanical or electrical artefact, then costs can increase dramatically.
We do expect the impact of all these software engineering techniques on the world of product design to change the design workflow. There are things the software engineer 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.
