Integrating Hardware and Software Development in Digital Product Delivery

Every day, software becomes more crucial to the way our world works. The more software that products contain, the more complex it becomes to develop them – and the more room there is for error. Meanwhile, the pressure to innovate and bring complex quality products to market faster is on more than ever. Add to that the challenge of efficiently managing the parallel development streams of hardware, software, and service innovation, ensuring transparency, and integrating all of these in a single product.

Manufacturers who don’t want to get left behind in the race to optimize complex product development need to significantly evolve their processes, systems, and team mindsets, or be replaced by competitors who have designed their businesses with complex products in mind from the ground up.

The key to this evolution:

• Establishing a methodical view of the overall system
• Using methods from systems engineering
• Opening up the organization to interdisciplinary thinking
• Leveraging the right PLM/ALM tools

From a business perspective, these developments represent both an opportunity and a challenge for manufacturers. An opportunity because, given increased competition as well as pressure to innovate, software-driven products make it possible to speed up development times as well as pave the way for completely new business models.

But what makes it a challenge?

Interdisciplinary teams

From the product developer’s perspective, even if variance decreases on the mechanical side, the complexity of the overall system increases because of all that software and the tight interrelation between these components. And on top of that, there are often different development teams behind the software itself that all manage innovation cycles in their own way and at their own speed. Orchestrating their work and integrating these parallel development streams is difficult.

System validation

Manufacturers must also consider how the overall system can be validated, especially in the context of safety-critical products. Depending on the industry and product in question, standards require every development step and change to be traceable back to the original requirements.

Disconnected Toolchains

The toolkits used for software development have evolved into what we know today as Application Lifecycle Management (ALM), and its process model has been incorporated into modern Systems Engineering. However, in many companies the focus was and still is on managing the many individual components. Ensuring consistency from the requirements specification through to the finished product is not always supported by a Product Lifecycle Management (PLM) concept (method & tooling) that has been established consistently throughout the company.

We can observe the following tendencies when it comes to integrating growing amounts of software in companies that grew up focusing mainly on mechanical and electromechanical products:

Approach A: Treating software as a hardware appendage

This is when the software is seen as an extension of or addition to hardware (something along the lines of “that little bit of software is just another part number”). Software components are equated with electromechanical components and are assigned a part number. While you may still be able to identify at least the ECU in a product structure, it will ultimately be impossible to identify all the mutual dependencies in a flat BOM.

Approach B: ALM and PLM living side by side

In some cases, an independent parallel ALM world is set up alongside the PLM world. This presents a situation best described as “I don’t know what they’re doing over there, but I’m not interested either”.

Freed from the constraints of electromechanical development, the software developers can fully embrace their dynamic capabilities in the ALM world. Software is optimized to meet current customer requirements in short iterations and in a very agile manner.

However, what is usually overlooked in a scenario of complete separation is mutual synchronization between the worlds of PLM and ALM. Unfortunately, this becomes an inconsistency that is carried over into production and the finished product

Unfortunately, neither scenario outlined above is ideal for the functional symbiosis between mechanical engineering, electronics, and complex software.

The “fine art” of optimizing software-driven product development lies in establishing processes, methods, and tools that give all involved parties transparency, an efficient hub to collaborate, and all the tools they need to flourish.

That being said, all the separate domains still have to be coordinated to ensure that the end product meets all the requirements and functions as a single unit. However, this is not just a question of tooling and methodology. It also requires a wide-spreading and deep organizational change, the willingness for which is crucial. It is recommended to assign someone to take an active role in overseeing the changes and provide strong guidelines for coordination in your organization.

Next, the collaborative development process needs to be actively controlled in the complex environment of technology development. Methods used in systems engineering provide a suitable foundation. These already include extremely useful toolkits that can be used to tweak all the components of a product or system to the shared requirements.

Whether this involves implementing one of the systems engineering standards exactly as specified or merely using it as a guideline is almost a matter of preference – unless, of course, you have to provide proof of compliance with specified standards to your customers or other stakeholders (as required in some industries), in which case, it becomes highly important.

The methodological foundation

It is crucial is that your company chooses an appropriate procedural model (such as the V-model, for example) and uses it much as you would a compass.

What does this mean in the context of a software-driven product? It is vital that at the very beginning, you think about what the product should be able to do and what other requirements (e.g. standards) it has to meet. This should be done as impartially as possible and without a specific approach in mind.

The steps which follow include:

• Describing what your product should be able to do
• Divide the system up sensibly in the architecture phase
• Providing an initial abstract definition of the interdependencies
• Creating a synchronization mechanism

It is important to keep in mind that despite every effort to keep things simple, the interdependencies between hardware and software subsystems can quickly become very diverse and complex. It is therefore essential that your IT landscape helps you keep track of all these interdependencies as best possible.

Establishing the type of method model highlighted above lays a foundation that will enable you to meet the challenge of developing software-driven products reliably throughout the development process. End-to-end systems engineering, in particular, provides crucial support.

Most companies today are already putting much of these concepts into practice in one way or another. There is often simply a lack of optimized and more target-oriented coordination, which can be solved with the right mindset shift, by putting someone specific in charge, and by using adequate tooling to support your effort.