What is DfX?

In product development, typically many stakeholders and disciplines are involved with lots of unclarities and uncertainties, making it a challenge. Design for Excellence (DfX) helps to identify needs and design directions for specific stakeholders and functional areas of a system. Often needs are conflicting or even contradicting and trade-off decisions have to be made.

When viewing DfX from an agile perspective, we find many opportunities but also challenges. As agility is a strategic choice it is one of the influencing factors in the trade-off decision. This means that a decision can be made to allow an increase in product cost or development spending for this. Some examples for DfX in combination with agile hardware are:

• Design for Sales – Design for high degree of configuration even late in the sales proces. Split the design in a basic model with various add-on options. Design services that can be sold with the product.
• Design for Supply Chain – Use simple and overdesigned interfaces or interface adapters so multiple suppliers can be selected and changes can be made without changing the interface. Use functional specifications instead of detailed requirements. Use contract first design (interface determined early so co-developers can already start).
• Design for Manufacturing – Avoid multi-material/processing in a module. Design in modules with simple and quick assembly interfaces (click-on/off, universal multi-cable data connectors, databus, …). Oversize module casings to allow change for larger components.
• Design for Service – Design easy to remove/refit cover plates. Design one-click on/off modules that are easy to reach. Add data sensors to predict and schedule maintenance.

Design patterns

Design patterns are known good practices that can be useful to find solutions for common design challenges in many different situations. For example the singleton pattern that tells us that in some cases it is best to use a centralized approach or single interface like with a central safety control unit. As most design patterns originate from software development, not all can be used for hardware design and they do require a bit of creative re-thinking

Examples of design patterns for hardware development:Patterns:

• Singleton – Using a central unit and/or using standard components. For example use of a multi-connector instead of 10 loose connectors or databus. Another example is using a touch screen instead of a dashboard with many buttons.
     
• Abstract factory – Describe a family instead of the exact object. For instance the wheel of a car can be chosen freely as long as it is within a range of sizes and weights.
  
• Builder – Using a specification that does not prescribe production method and allows for different means of production.
• Factory method – Only describe the interface and let co-developer decide what to build (contract first).
• Lazy instantiation – base model with add-ons that can be produced elsewhere and added later. Or, using a temporary stub or simplified version.
  
• Prototype – Use a skeleton / basic model and replace/expand it later. For instance a wooden frame to be replaced by a plastic one.
  
• Adapter or Wrapper – Use of adapter plates or connectors in case something with a different interface needs to be connected without changing the original interface.
  
• Bridge – Similar to an adapter but then as a standard solution (adapter is only there when needed, the bride is always there). Used when objects to be attached vary a lot.
  
• Decorator – Sometimes referred to as form-fit-function. It’s about adding functionality to a component or (sub)system without needing to change the original. This allows for dynamic exchange a part for a newer one with more functionality (or back).
  
• Facade – To mask the complexity of the underlying (sub)system. For instance a cover, cabinet, cable box.
  
• Module – Components grouped together so they can be transported and assembled a one. Like a the gripper module of a robot. This allows changes to the module without affecting the rest.
  
• Proxy – A temporary replacement like a stub or dummy part.
   
• Flyweight – Taken some liberty here, but it could be the use of standardized parts and limit variance and foster reuse. For instance using only M10 socket screws.
• Bus – Use of an interface that can connect multiple objects. For instance ASI-bus or a mounting rail. Also, shared use of data, power or fluids like units sharing hydraulics.
  
• Overdesign – Overdesign a part or interface on purpose to allow for changes later without having to modify it. For instance, additional holes in a connection plate, use 2.0mm steel instead of 1.8, use an oversized cabinet so larger components will still fit.
  

Data Driven Design

Data driven design uses data to improve design and support decision making. More and more data gets produced every day and being able to put it to use has great advantages. It can be useful for customers (informing them on how to improve usage of their system for example), for service (do we need to change that bearing soon?), and for development (what features are never used?

Examples of things you can measure are: machine run hours, failures, down time, user interaction, user preferences, usage, wear & tear, power consumption, etc. You can measure during DevOps (proto/pilot, user panel testing, endurance tests, auto-install/commissioning, manufacturing issues, etc.), or during usage/service (questionnaires, data retrieving via sensors, video recording, etc,).

Depending on where data is produced, we need to collect and transport it to central repositories so it can be accessed and used. Besides the technical challenges (e.g. moving sensor, inside radioactive area, etc.), there are also challenges like security, fire walls, privacy rules, network capacity, etc. Even more so, when collecting large volumes and perhaps sensitive data (e.g. radar output of a warship).

The data collected needs to be prepared so it can be used to analyse and make decisions on what to do with it. Preparation is for example: filtering, ordering, merging, visualizing, etc. Data analysis is trying to make sense of the data provided. Decisions may involve: stopping, proceeding, altering a design/feature, change user interface, increase quality, etc. To start collecting data, it’s important to start with the end in mind: what’s the hypothesis? What are you trying to prove/disprove? This can vary from: a user prefers this over that, or, actual wear data to decide on maintenance schedule.

You can distinguish 3 levels: data driven, data informed, data aware. Data-driven design implies that the data that is collected determines (in other words, drives) design decisions. data-informed design, where a team takes data as only one input into their decision-making process. data-aware design where decisions need to be taken not just from data but back to data collection practices.

Behavior and Test Driven Design

Behavior driven design is a highly collaborative process aimed at clarifying expected system behavior. Developers collaborate with domain experts (e.g. customers or representatives) and quality people (e.g. QA or testers). This trio is also nick named ‘the three amigos’.

Resulting features are typically written in a more human understandable syntax. They start with a simple and clear title. Then a description in the user story format “As a <user role> I want <specific goal> So that <specific reason why>”. Next, the acceptance criteria are written in scenarios using the “given, when, then” format. See example below.

After creating the feature, the next step is to create a failing test and repeat the design/build/test cycle until the test passes. The test is preferably automated (e.g. via robot), but can also be manual which is common for hardware development.

Next step is to split the feature and create test driven stories which are often not user centered, but technical stories. The format for technical stories is roughly the same, but without the “As a” part (just goal and reason why, and test scenarios).

Set based design

For every idea an investment is required so from efficiency perspective we tend to reduce the number of options to a minimum, preferably even to zero, the perfect solution, first time right. When we continue and learn, we may find that the solution was perhaps not so perfect and it’s back to the drawing board. This may result in significant loss of time resulting in a high cost of delay. To prevent this, set based design tries to keep options open while it’s economically sensible to do so. This depends on all kinds of risks versus development cost and cost of delay. The higher the risks and cost of delay, the more options you want to keep open. Not every option has to be developed in all detail. Just enough to prevent you from going all the way back. To be able to quickly switch from one solution to the next, it helps to have an architecture and design that supports this. For instance modular design with overdesigned interfaces.

Generative Design

Generative design is an iterative design exploration process that typically uses AI (Artificial Intelligence) driven software to generate design options that meet certain constraints and objectives like loads, range, performance, etc. The software can rapidly explore an enormous amount of options, produce design options well beyond expectation and imagination since it is not hindered by an engineer’s beliefs and assumptions, and allow engineers to draw on expert knowledge encapsulated. There can be many uses for it like solving complex problems (e.g. heat distribution optimum), optimum cost to performance, etc. When presented with design options, the engineer can then explore further by changing or adding parameters, fine tune a certain region or component, etc.