This week, Mike Evans discusses the business initiatives that respond to consumer and business demand for smart products and devices.
Experts at industry analyst and market consulting firm Cambashi contribute a regular blog to TM titled Silos Changing exploring how new software applications enable manufacturers to implement business initiatives for the new economy.
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 customised by the customer.
This wide scope of possibilities causes more complexity. The requirements are wide in scope and it’s difficult to envisage 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 organising into departments and firms that specialise in a particular expertise tends to create barriers.
A 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-optimisation.
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 software people come from pure computer science backgrounds. However, this is also an opportunity. Different engineering disciplines can learn best practices from each other.
The world of software development has learnt 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-organising 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 pre-requisite 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.
In future blogs, we will go on to write about other potential deployments that respond to these business initiatives to address consumer and business demand for smart products and devices.
