Product line development: tools, methodology, architectural patterns, and AI

Requirements for product line development

Product line development aims to make development and operating processes for highly varied products efficient and sustainable. The focus is on four key requirements:

• Fast and efficient derivation of new product variants by configuring existing components
• Configuration and commissioning by application experts – without in-depth software development knowledge
• Efficient maintenance and servicing throughout the entire product life cycle
• Support with certification, if required by regulatory requirements

Economic realization of product line development

The economic potential of a product line development can only be fully exploited if domain engineering is also implemented efficiently. The central task of domain engineering is to provide tools and models that enable technically qualified employees—without special software knowledge—to configure and commission products.

This requires the use of domain-specific description languages that emphasize the technical aspects of the product and enable intuitive operation.

The development of such languages requires extensive experience and suitable frameworks – building something from scratch is generally neither economical nor effective.

A central principle of product line development is therefore the reuse of existing artifacts. This principle should be applied consistently at all levels:

• Reuse of proven methods
• Reuse of proven architectural patterns
• Reuse of existing software components

ProSign can draw on a wealth of experience with such artifacts—even though many of them were originally created outside of a traditional product line development process.

This document presents selected components from the ProSign portfolio and shows how they can be used specifically for successful, practical, and economically viable product line development.

Tools

ProSign uses iCon-L as the central technology for implementing its product line development strategy. More than 30 years ago, iCon-L was developed—initially intuitively and without a formal theoretical basis—as a tool that today proves to be ideally suited to the requirements of modern product line development.

Methodology

This article only covers the theoretical background of product line development in a nutshell. In the literature, there’s usually a distinction between two levels and two key processes of product line development:

This structure forms the methodological foundation for the systematic planning, development, and implementation of diverse product families.

Variability modeling

Variability modeling is the central element of product line development. It defines which aspects of a product are configurable and how flexibly product variants can be adapted to different requirements. The success of a product line project depends largely on the quality and clarity of this model.

There are various approaches to designing variability. One common method is the so-called 150% model, in which all conceivable features and options are combined in a higher-level model. Within the framework of application engineering, the specific features required are then activated or deactivated.

When modeling variability graphically, a different approach is often taken. Instead of an overloaded overall model, a flexible core model is created that already represents a possible product configuration but can be adapted as needed.

iCon-L follows this approach: The core model forms the functional basis, which can be adapted to specific applications by adding or removing components such as sensors, actuators, or other assemblies.

Example: Machines with extracorporeal circulation technology

Figure 1 shows the core model of a product line for machines with extracorporeal circuits. Variability is particularly high in this case:

• Sensors, actuators, and functional units can be flexibly combined.
• New elements can be added.
• The basic circuit structure is customizable.

The application developer is limited to the building blocks provided in the system—custom types cannot be freely defined, which ensures system integrity.

A similar principle applies to the machine’s sequence control: Here, too, the developer can make changes, add elements, or remove elements within predefined sequence elements. Depending on approval by product management, control sequences can also be customized at lower levels.

Figure 1: Variability model for machines with extracorporeal circulation

Digital Twin

The models created in iCon-L are fundamentally hardware-independent and declarative in structure. This means that they describe what is to be achieved, not how it is technically implemented. This abstraction makes iCon-L models particularly suitable for simulations and virtual commissioning.

At ProSign, the use of a digital twin for the entire system has proven to be extremely efficient. The software can be tested and validated in a simulated environment early on in the development phase – without the need for real hardware.

A system architecture pattern described later in this document is based on a distributed multiprocessor architecture. For the first development stage of the digital twin, this aspect is deliberately ignored: the system is modeled as if a monolithic central control system were being used—communication between the processors is initially omitted entirely.

Figure 2 shows this simplified structure of the digital twin.

Figure 2: Digital twin without communication between processors

Architectural Patterns

Tried-and-tested architectural patterns form a stable foundation for successful product line development. Their particular value becomes apparent when they not only work in individual projects, but have also proven themselves across different product lines. Even though these patterns were originally developed for specific applications, they are so flexible that they can be easily reused in different system contexts—a key quality feature of good architectural patterns.

Over the many projects it’s completed, ProSign has developed a bunch of these architectural patterns just for use with iCon-L. These are used consistently and successfully in current customer solutions.

Examples of established patterns are:

• System architecture patterns at the control level
• UI flow patterns for controlling individual pages using an automatic system
• Automatically controlled central management of an automation unit
• Communication patterns between distributed controllers

System architecture patterns at the control level

A central architectural pattern that ProSign regularly uses is shown in Figure 3. It shows a typical system architecture for the control level – modular, scalable, and particularly suitable for applications with increased security requirements.

Typical fields of application are:

• Laboratory automation
• Condition monitoring
• Machine controls
• Medical technology systems

If there are no safety requirements, the “supervisor” can also be a dedicated assembly controller within a machine.

Multiprocessor System

Distributing tasks across multiple processors is a proven principle in automation technology. This approach is particularly advantageous when the computing power of modern standard PCs is to be utilized, but at the same time, strict real-time capabilities and functional safety requirements must be met.

Although a distributed architecture leads to greater system complexity, the advantages clearly outweigh the disadvantages:

• Better scalability
• Specific load balancing
• Increased reliability

Thanks to a specially developed MQTT communication solution, ProSign has succeeded in efficiently managing the additional complexity created by processor distribution. This means that the architecture remains clear and maintainable even as the range of functions grows.

MQTT

As a communication standard at the upper system level, MQTT (Message Queuing Telemetry Transport) has proven to be extremely reliable and flexible in our projects. MQTT offers decisive advantages, especially in distributed architectures:

• Stable and low-latency communication between system components
• High flexibility when connecting different devices and subsystems
• Scalability up to complex multiprocessor

All message flows can be coordinated via a central MQTT broker – both within a PC (between processes) and between multiple control units in the network.

A special iCon-L function block also enables structured data models to be transferred directly via MQTT. This not only simplifies configuration, but also efficiently supports the transfer of complex data structures – with full compatibility to the MQTT standard.

A further advantage: By using MQTT, digital twins can also be equipped with realistic data communication without the need for adjustments to the application software.

Figure 4: Architecture pattern for MQTT communication

Figure 5: MQTT can transfer entire iCon-L structure data

CAN-Bus

The CAN bus (Controller Area Network) is integrated into the ProSign system architecture pattern as an optional communication component. Its use significantly increases the flexibility and modularity of the product line.

Typical advantages result from:

• Easy connection of additional I/O modules
• Extension of automation to decentralized subsystems
• Robust, real-time communication at the field level

The integration of the CAN bus allows complex systems to be divided into functional units in a targeted manner – a significant advantage for scalable, maintainable, and service-friendly architectures.

Fully extended digital twin

As already described in the Methodology chapter, the digital twin plays a central role in model-based product line development.

Figure 6 shows the system architecture of the digital twin at an advanced stage of development – i.e., before the physical distribution of the software to multiple controllers, but already with all relevant communication structures in place.

Unlike the simplified version described in the methodology chapter, which initially dispensed with interprocess communication, the complete digital twin also realistically maps the communication relationships between the processors. This enables even more precise simulation, including load behavior, latencies, and error responses in the overall system.

Figure 6: System architecture of the digital twin with simulated communication between the processors

Figure 7 shows the user interface of the digital twin. This interface can be used to simulate the entire operating sequence realistically – including all controls, displays, and feedback.

This not only enables early validation of user guidance, but also practical training for future operating personnel even before the actual hardware is available.

This aspect is particularly important in the context of medical devices: early usability testing contributes significantly to risk minimization. Incorrect operation or misunderstandings in the interpretation of displays can cause considerable damage—a digital twin helps to identify and address such risks specifically during the development phase.

Figure 7: Digital twin in a virtual machine

Commissioning and troubleshooting

A key objective of product line development is to enable service employees — even those not directly involved in software development—to configure and commission products independently.

This requires an intuitive, visually supported configuration environment that can be operated without in-depth programming knowledge. The model-based approach with iCon-L meets these requirements exactly:

• Domain-specific symbols and
• Clearly structured architectural patterns

promote understanding and make familiarization considerably easier.

In addition, integrated visualization functions, such as the live display of online data (see Figure 11), support commissioning, maintenance, and troubleshooting directly in the system model.

The combination of visual modeling, transparent data representation, and systematic structure significantly reduces complexity — a clear advantage, especially when providing on-site service.

Prospects with AI

One of the strengths of iCon-L lies in the linking and parameterization of function blocks that are developed as part of domain engineering or provided by ProSign.

With increasing progress in the field of artificial intelligence (AI), new possibilities are opening up—especially in the automated generation of function blocks. The potential of AI-based systems is already evident today, for example in the generation of hardware-independent source code for rule-based or algorithmic functions.

• Precise specifications are essential for high-quality results:
• Definition of inputs and outputs
• Definition of expected behavior
• Formulation of boundary conditions

Under these conditions, AI can deliver impressive results—and also automatically generate detailed documentation and test specifications for the generated component.

The building blocks generated by AI can be integrated into iCon-L in a structured manner and flexibly connected to real hardware. However, it is important to ensure that the generated code remains manageable—particularly in safety-related applications, complexity should be deliberately limited in order to ensure validity and maintainability.

Services offered by ProSign

In the context of product line development, ProSign offers a comprehensive portfolio of services that supports companies from the initial idea to full implementation.

Our services include:

• Technology consulting for selecting suitable tools, architectural patterns, and development methods
• Consulting in project management, tailored to model-based development processes
• Project management takeover if required
• Support in domain engineering, e.g., in the development of domain-specific models and function blocks
• Support for application engineering, including configuration management and testing strategy
• Entire project implementation – from conception to implementation to commissioning

Thanks to its many years of experience in safety-critical and regulated markets (e.g., medical engineering, railway and automation technology), ProSign offers practical, robust, and standards-compliant solutions for economically viable product line development.

(Publ. 9.05.2025 on linkedin)