Developing Software for Production Systems vs. Smart, Connected Products

In our hyper-digitized times, more companies than ever before employ software in smart, connected products. For some, that software drives automation in complex production systems in manufacturing, packaging, and other factory environments. For others, that software drives the behavior of smart, connected products like cars, home appliances, and more. In all, these applications are vast and often complex.

The software development efforts behind these developments have some commonalities and dramatic differences. In this post, we examine the similarities and differences between the software development strategies used for these smart products and our production systems.

Getting Software to Run on Target Hardware

Whether a company is developing a smart product or a production system, every piece of software must work with a corresponding piece of hardware. But getting the software to run as it should and without errors is extremely challenging. Compatibility and performance issues are common hurdles. Let’s start by looking at what is different or similar between developing software for production systems and smart, connected products.

• In smart, connected products, engineers develop embedded software to run on new-to-the-world circuit boards, which are part of larger, sometimes pre-existing electrical systems.
• For production systems, engineers develop software logic that runs on programmable logic controllers (PLCs) and human-machine interfaces (HMIs), which also form part of a wider physical infrastructure.

Getting new software to run on target electronic hardware is the commonality. However, there is more in common between these development efforts. Under today’s compressed development schedules, engineers cannot afford to wait. With smart, connected products, they can’t afford to wait for prototype electronic hardware. For manufacturing production systems, they can’t afford to wait to assemble a manufacturing cell, line, or entire facility to start testing. In either case, no engineer can take the time to completely rely on physical verification and validation.

This explains the recent embrace of model-based approaches like virtual commissioning to test and validate our production systems. This strategy not only reduces the time required for validation but also lets engineers test different software-hardware iterations across a virtual production line long before they physically build or prototype anything.

For smart products, this virtual verification process is called model-based software development. The terms “virtual commissioning” and “model-based software development” ultimately serve the same purpose: they enable virtual testing of software behavior before doing anything physical. They’re synonymous. Model-based software development provides the same benefits as virtual commissioning, just within the context of a smart product.

Net-New vs. Off-the-Shelf Target Electronic Hardware

While the concept of getting software to run on hardware is similar for both environments, the nature of the hardware in question is very different when comparing smart, connected products and production systems. This is because, while production systems have been designed with interconnection and interoperation in mind for some time, smart products have not.

The emergence of smart, connected product is a relatively new phenomenon compared to production systems. This new class of product only became possible recently due to improvements in processing power and device miniaturization. Without these improvements, engineers could not integrate the sensors, microprocessors, data storage and connectivity required to enable the smart functionality of these devices. In contrast, computerized controllers have been a part of production systems for decades. They have become highly standardized, especially in programming.

The target hardware found in a smart device often features new-to-the-world circuit boards and even integrated circuits housed by electronic control units (ECUs). But trying to get brand new software to run on brand new hardware poses a significant challenge because there are so many unknowns. The system complexity of smart products invariably increases as time passes as, for example, engineers add more sensors and other components to the ECU to provide extra functionality. This adds more unknowns to the system, which further exacerbates the situation. And that’s not all. ECUs are often networked together, especially in complex products like cars and planes, which introduces another layer of complexity to the system. Yet, standardization efforts in the smart product arena are still in the nascent stages.

When it comes to production systems, the target hardware includes PLCs and HMIs. These hardware controllers have been around for years, with new generations released at regular intervals. However, these controllers are generally more stable platforms upon which to develop operational logic and the software that drives it. This is thanks to their longevity in the market and, consequently, the lack of relative unknowns. These individual controllers are also regularly interconnected to form a larger production system. However, the same controls generally communicate with one another, further alleviating some of the complexity for these production systems.

What’s the takeaway? Developing software for PLCs and HMIs in production systems is actually easier compared to the equivalent with smart, connected products. Virtual commissioning can make that effort far easier.

Virtual Verification Process is the Same

There is a final similarity when developing the software for production systems and smart, connected products: the virtual verification process. Virtual verification expedites the development of software for both systems. While there are differences between the virtual verification of smart products and production systems, the processes involved follow roughly the same structure. Virtual verification is a multi-staged and progressive process. In developmental order, its key steps are:

• Model-in-the-Loop testing: In this first step, engineers build a software model, not software code. They use this model to test behaviors and to uncover errors by connecting it to a 1D system simulation. This fast, simple method of laying out the software, and testing it with a simulation, allows non-software engineers to define and test their logic in a completely digital realm without actually coding software.
• Software-in-the-Loop testing: Here, the resulting model logic is compiled into software. From there, it undergoes testing and optimization with a 1D system simulation. This produces a working version of the software for use by the smart product or production system. This lets engineering verify that everything still works while moving from the software model to compiled software.
• Hardware-in-the-Loop testing: This step involves testing compiled software connected to a physical test system. The progression towards this step through Model-in-the-Loop and Software-in-the-Loop make this a far lower risk step. Engineers have verified behavior and software-hardware compatibility along the way. In these methodologies, this becomes simply a final, simple step.

As the virtual verification process is the same when developing software for smart products and production systems, businesses can cast a wide net when hiring software and installation engineers as the same basic skill sets are applicable. This is because translating the virtual verification process between the model-based software development for smart, connected products to virtual commissioning for production systems shouldn’t be too much of a stretch for these software professionals.

Summary and Recap

• The software development processes for smart, connected products and production systems contain both similarities and differences.
• In terms of similarities, smart products and production systems both need to run software on their target hardware, and model-based approaches like virtual commissioning can expedite this process.
• However, the hardware found on net-new smart products is very different compared to the off-the-shelf target electronic hardware used by production systems. For smart products, complexity and compatibility issues can hamper software development efforts because of the subsequent range of unknowns.
• But the virtual verification process is the same for both environments, allowing businesses to cast a wide net when sourcing software professionals to conduct these simulated tests.

Recommendations

• Use a virtual verification process to accelerate software development efforts for the production systems.
• While the virtual verification processes are usually the same for both environments, the hardware is not. As a result, management may need to factor in the compatibility and complexity issues that often crop up for smart products.
• When recruiting a virtual verification professional, businesses do not need to limit their search to those candidates with specific hardware experience – these skills are transferable thanks to the similarities of the processes involved.