We Take a Look at Why Companies are Adapting Their Processes to Meet Today’s Product Development Challenges
Manufacturers are having to evolve the way they develop complex systems to be able to handle these changes. In this blog, we’re going to be comparing the older traditional ways of developing and verifying your products with new, modern approaches.
THE OLD WAY – Design, Build, Test
The old way of doing things works along these lines:
With the high-level product requirements defined, systems engineers distribute them across the teams. The requirements that a team receive will depend on who the systems engineer deems to be ultimately responsibility for what the requirement addresses.
Each team then expands on the high-level requirements; documenting sub-requirements, building development plans, and starting the design work itself.
They’ll be some informal communication between teams if one team’s work has an impact on another. However, teams will mainly work in isolation, performing simple, abstract calculations and recording them on a tracker – normally in the form of a spreadsheet.
This approach means everyone gets on with what they’ve been assigned. When all the teams are done, prototyping and testing begins.
When the end product’s simple, this way of working’s fine. But in the real world, issues come to the surface when there are inconsistent design approaches between teams, particularly as a product becomes more complex.
Thinking about how a team could deal with a tricky requirement lets you appreciate how this disjointed approach can result in problems:
One team might push back on a requirement and ask for a concession with the belief that it can’t be fulfilled.
Another team might have a lenient interpretation of a requirement, allowing their designers more creative freedom to only satisfy the original requirements constraints in part.
And another team might satisfy all the constraints of a requirement with no issues.
Whatever way you look at it, there’ll be an issue lurking in the shadows…
The team’s designs are bound to diverge due to the variety of design approaches that can be taken at every turn, dependent solely on each isolated team’s interpretation. The problems will only emerge when each of the designs are brought together later in the product development lifecycle. And each team’s results could be a long way off the mark if there isn’t a mature, tried-and-tested way of conducting spreadsheet calcs. If that’s the case, inadequate designs can progress straight into the testing phase. With limited communication between teams, and inconsistent design approaches, the problems soon mount up.
A prototype is created by combining the designs, and immediately problems come out of hiding. This results in the prototype failing when tested against the original requirements. To fix the problem, the designers make changes and create another prototype at notable expense … and again, it fails. A toing-and-froing of design changes goes on. Eventually, the prototype passes testing, albeit at considerable cost with added delay.
THE NEW WAY – Model, Analyse, Build
The new way of doing things and the old way are poles apart. Consistency, collaboration and visibility are at the centre of the new approach – everyone works together to build a complete digital model of the system. The model itself incorporates requirements, system structure, system behaviour and parametric constraints whilst enabling each team to concentrate on the piece of the model that relates to their speciality.
It’s a highly dynamic way of working and one that we call model-based systems engineering (MBSE). Changes can be made to the model whenever they’re required, with the impact of those changes being immediately visible to the affected teams. The system effectively becomes a single source of truth that governs these changes, allowing engineering and design teams to coordinate their activities.
When the detailed design phase gets going, each team has a defined design envelope that they’re intended to stay within. However, if one team’s design goes beyond the bounds of their envelope, a systems engineer weighs up the impact on the system model as a whole to try to preserve its integrity. A reassignment of weight allocated from one team’s design envelope to another may be all that’s needed.
With MBSE tools like the CATIA Magic toolset, teams are enabled to simulate and analyse the impact of designs outside of their design envelope. This means that design feasibility can be gauged in context of the entire project’s requirements. With every sub-system designed as part of a broader MBSE systems model, individual teams have confidence in their designs with the knowledge that their work contributes towards ensuring the overall system fulfils its requirements.
Validation and verification gates are used to ensure model consistency as the system model moves from design to prototyping, testing and beyond. With an MBSE approach, there are no problems waiting to jump out unannounced when the design moves from the virtual to the physical world – that’s because MBSE enables the design to be meticulously analysed and simulated which helps uncover and resolve issues early in the development process.
Clear visibility and communication of the design to the engineering teams is enabled by the common digital thread of the MBSE design process. With this approach, all the design teams feel assured that the sub-systems that they’ve been responsible for performs as expected, and in-turn so does the complete system. Basically, this new way of working offers organisations consistency and a means of collaborating to accelerate product development.
WHAT’S YOUR WAY?
The new way of working, through MBSE, has clear benefits for any organisation. So, if it’s not a journey you’ve started on, then I’m sure you’d agree it’s something to consider!