DSL4DPiFS – a graphical notation to model data pipeline deployment in forming systems

3.1 Expert workshop-based procedure to derive requirements for DSL4DPiFS

Metal forming technology experts from four German research institutes participated in this workshop series (Table 1). They represent four different research projects and metal forming processes (Institute B: Hot Impression Die Forging; Institute C: Metal Wire Punch-Bending; Institute D: Multi-Stage Sheet Metal Forming and Institute E: Sheet Metal Deep-Drawing) included in the SPP 2422.^[1]

In the first workshop, the existing DSL elements were introduced, followed by Q&A and discussion regarding their applicability and understandability. Templates for graphical modeling were provided as a Microsoft Visio library for conducting the workshop. Afterward, the teams from Institutes B–E were encouraged to model their corresponding systems using the existing DSL. During the application of the DSL, elements that are difficult for metal forming technologists to understand or present weaknesses, e.g., lack of expressiveness, were identified.

In preparation for the second workshop, DSL experts (Institute A) evaluated the models developed by the other institutes. This workshop series aimed to deepen the understanding of metal forming experts on the DSL and identify its weaknesses, deriving additional requirements for its extension. The five derived requirements and their corresponding model extensions will be introduced in Section 3.3. A third workshop was conducted to finalize the DSL extension, summarized as DSL4DPiFS. Finally, this DSL4DPiFS was used in the fourth workshop to refine the system architecture model using the added notation elements, which will be introduced in Section 4.

3.2 Introduction of the existing elements reused for DSL4DPiFS

To enable the utilization of data-driven methods in metal forming processes, it is necessary to consider the interdependencies of sensors and actuators as data sources (data acquisition) and the system architecture together with the available data pipelines [19]. Data processing, transformation, storage options, and data analysis models should be modeled if it’s feasible to use a DSL. Finally, the questions to be considered are: (1) What physical quantities of which process steps within which metal forming process need to be measured in what way? (2) How should indicators of metal forming processes in different formats and semantics, collected by heterogeneous devices, be processed, transmitted, aggregated, and analyzed?

The data flow view should be included to illustrate these questions in detail. Conversely, all operations on data are executed using heterogeneous devices, serving as carriers or transmission media and calculation power providers. This entails allocating computational and storage resources and establishing communication and connectivity. Thus, describing the hardware view is crucial for transparently elucidating the deployment of data pipelines in metal forming systems. Existing DSLs proposed by previous work enable the representation of the hardware deployment of CPPS [7] and data flow [8] across the software hosted on this hardware, providing two views for system description. A summary of the selected notation elements is given in Table 2.

Table 2:

Selected notation elements from the existing DSL notation library [6], [7] as a basis for further extensions (DSL4DPiFS).

	Notation element		Description
Applicable for both views	a		Specified communication or process-related time behavior requirements (left). Communication-related timing behavior properties (right) of networks, hardware, or software, e.g., latency and sample time.
	b		Specified data flow-related time behavior requirements (left). Data flow-related properties (right) of networks, hardware, or software, e.g., semantic, protocol.
	c		Specified architecture-related requirements (left). Architecture-related properties (right) of networks, hardware, or software, e.g., file type and redundancy of components.
	d		Element for additional, non-formalized information. Based on the UML comment construct.
	e		Digital (square) or analog (circle) sensor/actuator signals.
	f		Calculated data/variables based on other signals and models for data analysis.
	g		Signal, variable or model element. The symbol includes the element type and corresponding name defined by unified identification (UID).
	h		Requirements/properties that refer to a hardware component or software functionality. From requirements/properties to system node.
	i		Arrow to relate signals, variables, and models to systems or nodes. The arrow is aligned with the direction of the information flow. If the system calls the model/data, it is directed from the model/data to the system node.
Hardware view	j		Software functionalities for data analysis deployed on hardware. The left is for data forwarding (UID FW1), and the right is for data analysis (UID DA1). It can be combined with signals, variables, and models. Possible software functionalities are available in Table 3.
	k		Bus coupler with specific interface and I/O terminals. The example symbol represents a bus coupler with UID BC1 for profibus DP (UID of interface DP1) with eight digital inputs and eight digital outputs. (Deployment of software functionalities is not possible)
	l		Hardware with computational power (PC/PLC/ID as hardware type) with interface for communication. The example symbol possesses a single Ethernet adapter (ETH1) and a software functionality for data translation (TR) is deployed. (Deployment of software functionalities is possible).
	m		Network, fieldbus, or other physical data transmission medium (thick line) with connections to the devices (thin line) and empty UID identifier.
Data flow view	n		Source for the data flow. The element refers to a concrete software functionality deployed on the hardware. The naming scheme for UID is (UID of the hardware system). (UID of software functionality).
	o		Sink for the data flow. The element refers to a concrete software functionality deployed on the hardware. The naming scheme for UID is the same as element n.
	p		Sink-source for the data flow. It can receive, process, or distribute new data. The element refers to a concrete software functionality deployed on the hardware. The naming scheme for UID is the same as element n.
	q		Data flow in batch packages (upper) or a continuous stream (bottom). The element refers to the network transporting the data or the respective hardware system.

In the hardware view of the existing modeling notation, machines can be abstracted as programmable logic controllers (PLC), and data acquisition can either be realized by receiving signals from sensors connected with PLCs or by intelligent devices (IDs) with computational or storage power. Data transmission and communication between hardware can be described using interfaces, terminals, networks, and field buses. The notation for the software functionality deployment on the hardware enables a consistent mapping of both views through the explicit module “UIDs.”

Within the data flow view, the nodes representing software functionalities for “Data Processing” are divided into three categories: (i) data source, (ii) data sink, and (iii) data sink-source. In contrast, “Data Transmission” is divided into continuous and batch-based categories. Requirements and properties of the system in terms of time behavior (element a), data flow (element b), and data structure (element c) can be expressed and linked to the system nodes via the arrows i or h. Information that cannot be structured and formalized can also be added on demand using the annotation element d. As shown in Table 3, the enumeration table limits the optional software functionalities. These software functionalities represent individual procedures for data processing, necessitating a clear fine-grained decomposition of the data flow throughout the manufacturing system.

3.3 Required DSL extensions for metal forming systems

The following section introduces the weaknesses of the DSL identified during the workshops, leading to five required extensions of the notation.

Required extension 1 : Data split or branching. Existing notation elements for data paths (Table 2, element q) indicate the direction of data flow but lack expressiveness when data split or branching should be modeled. For instance, temperature data in metal forming processes can be used for data analytics and displayed to the human operator. Therefore, modeling complex data pipelines composed of different sources and destinations is particularly valuable in describing the data section flowing on the path after data split or branching.

Required extension 2 : Predefined rules as data flow trigger. The existing DSL distinguishes continuous from batch data flows (Table 2, element q). Predefined rules initiating sensor behavior or triggering data transfer have not yet been represented. Metal forming technologists at the workshops provided examples of essential practices such as sampling, inspection, and trigger-based activation of measuring devices. For instance, an industrial camera might only be triggered when process anomalies are detected or at certain time intervals, while other sensors may be triggered solely for selected products. Quality or vision sensors used for process or product monitoring may only collect data based on some predefined rules that require trigger-based activation for data transfer. Another use may involve the necessity of data on demand, e.g., generating a scatterplot of quality data. Consequently, trigger-based activation on data must be representable in the DSL.

Required extension 3 : Multi-functional signal processor. Signal processing tasks are realized either by third-party devices equipped with interfaces and computing power or by in-house developed computing units, with preliminary processing of the data gathered from the metal forming processes. During the workshops, metal forming experts indicated that third-party devices may be preferred over self-developed signal processors due to ease of use, better connectivity, higher reliability, and more straightforward implementation. A typical example is the signal processor, which amplifies or computes electrical signals from various sensors via interfaces to derive the desired measurement variables. The internal working principles of third-party signal processors, including control logic and data processing algorithms, are not easily accessible to system engineers. Engineers often focus on application-oriented aspects: interfaces, connections, and resultant data type. Due to the fine granularity of the existing modeling notation regarding the representation of the fundamental automation components, i.e., PLCs and terminals, the options for such third-party signal processing devices are constrained by the challenges of decomposing them [8], [10]. Additionally, signal processors with embedded computational modules and multiple interfaces lack an appropriate representation. Hence, addressing this issue requires an integral representation of third-party signal processing devices rather than decomposing them into fine-grained units in the hardware and data flow views.

Required extension 4 : Third-party software (black box). Like third-party hardware, third-party software solutions are used for data processing, visualization, and analysis. Such software may be integrated into measurement devices like cameras and profilometers or separately installed on a PC. It provides a convenient option for metal forming technologists deploying DPiFSs in both cases. Therefore, a compact representation of the third-party software is required, i.e., non-important or unknown details in the case of black box software can be omitted.

Required extension 5 : Enriched sensor properties. The requirements and technical specifications of the system regarding safety and reliability are fundamental when deploying sensors. Verification of whether the properties of the selected sensors meet the respective requirements can be conveniently achieved by including them in the system model. Since metal forming processes are often accompanied by significant impacts on and by environmental conditions, i.e., temperature, humidity, and vibration, information regarding the survivability of the sensor under extreme conditions is critical for reliable and effective data acquisition [3], [20]. The quality of the acquired data and the effectiveness of the implemented data-driven methods are subject to the data acquisition stage, which also depends on the accuracy and calibration of the devices. Beyond that, the sensor measuring principle is imperative due to the various characteristics of the different metal forming processes and space constraints. For example, the available working area in the frame of metal forming machines is often very small, requiring compact and precise sensors. Mounting an accelerometer on a tool to directly measure its movement may cause the sensor to burn out in extremely high-temperature environments. Thus, optical sensors that indirectly measure tool acceleration, for example, can be more reliable in such situations. However, the existing sensor notation only accounts for signal type (analog or digital) and variable type (e.g., REAL and BOOL), as well as the latency within the intelligent sensor [7]. This notation lacks considerations of sensor properties critical to the metal forming process and the effectiveness of data-driven methods. Detailing specific sensor properties is vital for effectively acquiring data from metal forming processes. Hence, the DSL should include these properties to offer more comprehensive information.

4.1 Proposed graphical extensions

For required extension 1, a new element within the data flow view is proposed, consisting of a dashed bordered square containing the identification of the extracted information. It indicates the data section flowing on the path after data split or branching, e.g., feature extraction and data backup for different destinations. A special arrow represents connections from the data section toward the data flow path.

Regarding required extension 2, a diamond element within the data flow view is proposed, inspired by decision notation in a classical flowchart, indicating that a condition should first be judged to trigger subsequent data operations. Like its usage in the flowchart, it can be added to a data flow path, with no data flow occurring if the condition is not fulfilled. Predefined rules as triggers for operations on data include “product interval,” “indicator constraint,” “stochastic,” and “heuristic.” The latter refers to decisions made through human intuition or observation with no apparent indicators or criteria. The existing notation element can already model the expected time interval-based rule for data-relevant operations (cf. Table 2 element a).

Required extension 3 encompasses hardware and data flow views to effectively represent third-party signal processors while considering the focal points of application-oriented system engineers. In the hardware view, interfaces, a critical concern for system engineers, are paramount for selecting and connecting heterogeneous hardware, necessitating its inclusion. Unlike conventional I/O interfaces in industrial automation, third-party signal processors may employ input-only or output-only interfaces, requiring their distinct representation to elucidate device connection. Therefore, the interfaces are separated into three levels: the upper level represents output-only interfaces, the lower level represents input-only interfaces, and the middle level represents the I/O interfaces. In addition, signal processors may also be equipped with local storage, a property with a non-negligible impact on the structure of the data pipeline. This implies the possibility of distributed storage/backup of data and can be introduced as an optional symbol, i.e., a cylinder. The computational power mainly amplifies or computes the physical signals from different sensors to implement signal processing methods and deliver the resultant data through the output interfaces. It may contain multiple basic software functionalities defined as white boxes in Table 3, such as aggregation (AGGR), data analysis (DA), transformation (TRANS), routing (ROUT), and forwarding (FORW). This third-party functionality noted as a black box is called PROC, i.e., signal processing, which may include several other basic functionalities. As a critical feature of data footprint, data storage is noteworthy for being visible instead of captured in the black box, thus appearing as a cylinder within the element’s main body.

Given the user-interest-independent nature of its working principles, third-party software for data processing doesn’t require decomposing like legacy software (LEG). For this reason, to solve required extension 4, a black box SOFT is proposed as an extension to refer to the third-party software without decomposition. However, knowing which basic functionalities included in the SOFT are utilized and which need to be captured through the annotation symbol is desirable. In addition, the name of the third-party software could be included.

To address the required extension 5, sensor-related information on common concerns between metal forming experts and data analysts is introduced. The enriched sensor description includes mandatory information, namely [Sensor Type], [Sensor Name], [Reference ID] in the hardware view, and [Sensor Type] and [Sensor Name] in the data flow view. The enriched information is not directly visible in both views, including [Reference ID], [Sensing Mode], [Environmental Conditions], [Accuracy], [Calibration] and [Mounting Position]. They are listed in the table Sensor Properties (cf. Table 4, bottom left table Sensor Properties) and can be queried based on [Reference ID]. Descriptive information about sensor properties is generally available from datasheets, so a placeholder “–” should be used when the information is unavailable or unknown.

In contrast to the existing free naming convention for UID, this work proposes to define a formalized naming convention for [Sensor Name], including the measurement object (i.e., the machine part to be measured), the measurement principle (i.e., the working principle of the sensor), and the variable to be measured. The complete sensor name is structured as follows: “MeasurementObject_MeasurementPrinciple_MeasurementVariable.”

[Reference ID] is hierarchically structured as “=Function+Location-Product%Type#Others” according to IEC 81346-1 [22]. It provides information regarding system purpose (=Function), spatial location (+Location), involved product (−Product), and component type (%Type) of an element within the system through a predefined syntax, with additional information (#Others). The semantics of each position can be specified depending on the internal organizational rules, where not all five parts must be filled in.

The sensing mode of a measurement device needs to be differentiated as contact or contactless [1] as it possesses interdependence on process design. This information is given as a row in the table Sensor Properties (cf. Table 4), i.e., [Sensing Mode]. Additionally, temperature, humidity, and vibration are especially susceptible to metal forming processes [23]. Limitations on maximum temperature, humidity, and vibration for effective sensor operation can be traced in the sensor datasheet, belonging to [Environmental Conditions], and are listed individually. The sensor property [Accuracy] is important in error estimation, system uncertainty quantification, and reliability estimation of the data-driven models. It can be defined through an absolute or relative quantity. On the other hand, the property [Calibration] directly affects the validity and quality of data acquisition [24]. Calibration and recalibration of sensors is a nonnegligible task due to the differences in environmental conditions during system operation and downtime, wear and tear [25]. Thus, a tuple is introduced containing the way the sensor is calibrated. The first term indicates the calibration reference of the sensor, whether it is calibrated as a group (“g”) or separately (“s”). The second item indicates the calibration method, i.e., point-based (“p”), curve-based calibration (“c”), or other methods (“o”) that should be annotated by unformalized information. The third item indicates the recalibration rules, which may be applicable to multiple sensors and are listed in a separate table, “Recalibration Rules” (cf. Table 4, bottom left), in natural language through numerical reference to the table Sensor Properties. Nowadays, hardware providers offer sensor calibration as a service, but the detailed calibration baseline and method are the companies’ know-how. Consequently, the tuple contains only two items, the first one being an “OS” indicating outsourcing, and the second one being a recalibration rule suggesting a call for service of sensor check and recalibration. If calibration is not necessary for sensors according to their specifications, “NN” is used.

Optional information, i.e., [Mounting Position], provides a more detailed information of the sensor’s location in the table Sensor Properties, presented as a natural language supplement to +Location in [Reference ID]. Since the syntax of [Reference ID], which is based on letters and numbers, does not allow for a precise and flexible description of the sensor mounting position, e.g., “3 cm lower left, at an angle of 30° to the tool axis”.

Each metal forming expert group evaluated the five extensions presented in this section based on the properties of their use cases (cf. Table 1 follow-up meetings). The coverage of their use cases concerning the proposed extensions is summarized in Table 5. The use case of Institute B involves all five extensions; the metal forming experts indicated that these are very beneficial for clearly representing their system. Although Institute C’s use case is temporarily not using any third-party signal processors, the experts also expressed their approval of this extension. They anticipated introducing a third-party signal processor to simplify the data acquisition system. Metal forming technologists from Institute D indicated that while they are not currently branching data in the system, the new notation element of extension 1 will take effect when the data pipeline is further developed.

4.2 Corresponding extensions to the underlying metamodel

As a more abstract and formalized representation of the graphical DSL, the metamodel enhances its scalability and evolvability and serves as the basis for machine readability. The proposed extensions can seamlessly integrate with existing DSL-based functionality, e.g., automatic system architecture generation, only if they are compatible with the underlying metamodel with four containers [21]. The software container corresponds to the data flow view, and the physical container corresponds to the hardware view. In contrast, the annotation container and the relation container provide auxiliary information and implement dependencies. In this work, only extended and new classes are excerpted in Figure 1. Within the software container (cf. Figure 1 top left), the first extension can be expressed through the existing class DataElement, which can, therefore, be regarded as a pure visualization of an existing metamodel element. The second extension corresponds to the new class DataFlowTrigger as an optional component of the existing class DataTransportRelation, whose possible values are listed via enumeration. As for the third and fourth extensions, the software functionalities PROC and SOFT (black boxes) result in the new class ThirdPartyFunctionality, which inherits from the existing class SoftwareFunctionality that can be installed on hardware components, serving as sink, source, or sink-source of data. The new class can contain several instances of SoftwareFunctionality.

Inside the physical container (cf. Figure 1 top right), the class SignalProcessor, i.e., the third extension, is introduced, serving as a solution for data conversion, connection with other devices, and data processing simultaneously. It possesses input- and output-only interfaces, which are introduced into the metamodel as new physical classes.

A new class, Table, is developed in the annotation container (cf. Figure 1 bottom), containing two subclasses for sensor properties and recalibration rules. An annotation regarding third-party software is also extended as a subclass FunctionalityAnnotation of the existing class Annotation.

Within the relation container responsible for mapping elements in different containers (cf. Figure 1 right), the new classes SensorTableRelation and FunctionalityAnnotationRelation are introduced. They represent the dependencies between the extensions in the annotation container and the respective classes in the software and physical containers. SensorTableRelation is realized by querying the corresponding Sensor Properties table via the property ReferenceID of IOTypeSensor.

5.1 Data acquisition system for a hot impression die forging process (Institute B)

The screw forging press is equipped with a data acquisition system (cf. Figure 2) for the utilization of data-driven approaches. The setup includes 25 sensors to measure different physical quantities on the ram or frame: piezoelectric sensors are used for force measurement, magnetostrictive sensors for position and displacement, and capacitive sensors for acceleration [26]. A structured representation of this complex setup presented as the main obstacle hindering interdisciplinary communication within Institute B, where documentation like connection instructions, device specifications, and sensor data sheets were used in isolation. As a solution, the graphical DSL4DPiFS-based system model integrates the important information within these documents and presents it intuitively and comprehensively. The deployment and connections of different devices are effectively depicted in the hardware view (cf. Figure 3) and the corresponding data flow view (cf. Figure 4).

Figure 2:

Sensor positions on the screw forging press (acknowledgement to Institute B for permission on the usage of the photographs).

Figure 3:

Hardware view of the data acquisition system deployed for the screw forging press covering extensions 3–5.

Figure 4:

Data flow view of the data acquisition system deployed for the screw forging press covering extensions 1–5.

In this use case, the internal convention for ReferenceID (according to extension 5) is screw forging press(= SFP) as a function of the whole system, +UID of the connected I/O device serving as location information, followed by the sensor’s serial number (%S*). The environmental requirements for a particular area can be derived by querying the enriched sensor properties. For example, the maximum operating temperature of the position sensors (=SFP+ES1%S6−9) on the ram is 85 °C (cf. Figure 3). This information can be found in the queried Sensor Properties table of (=SFP+ES1%S6). On the other hand, for force sensors (=SFP+ES1%S1−4), the maximum operating temperature is 70 °C, which requires the temperature to be under 70 °C around the ram.

The introduction of third-party devices (SP1, ES1, ES2, SP2, and ID_Radar) and software (SOFT1, SOFT2, and SOFT3) for data processing provides reliable solutions for data pipeline deployment, i.e., connectivity, synchronization, preprocessing, and analysis. They are represented by extensions 3 and 4.

SP1 amplifies and distributes the signals (=SFP+SP1%S1−2), one to ES1 for data integration and another to the controller of the presses (PLC_P) for a protective shutdown if the sensed pressure exceeds a preset value. Notably, the signal amplifier is a single-channel module, and the two modules used are combined into the multi-channel one (SP1) for model simplicity.

Interfaces of ES* are either input-only or output-only, with primary interfaces including analog input (ANAI) and synchronous serial interface (SSI). They integrate industrial PCs, providing local storage, data processing, and data analysis functionalities within third-party software (SOFT1 & SOFT2). PC_M supports user access to ES* via LAN interface and remote desktop protocol (RDP). The digital output signal, Trigger4Sync (element of extension 1), is activated and transmitted through ES1’s digital output interface (DO) to the digital input (DI) of ES2, initiating synchronized data acquisition when Ram_Magnetostrictive_PositionFL exceeds 18 mm within the preceding 50 s. Trigger4Sync is then relayed from ES2, passing through the optocoupler SP2, where the signal voltage is reduced from 24 V to 3.3 V before being transmitted to the Pico to trigger the radar signal acquisition. Consequently, ES1, ES2, and ID_Radar are triggered simultaneously via cable connection. The three occurrences of the Trigger4Sync imply the communication and control logic of the devices, and they also provide sufficient grounds for data integration based on timestamps.

The oscilloscope (ID_Radar) is the data acquisition device for radar signals that uses high-speed analog inputs via eight channels. In contrast, two oscilloscopes are deployed in the setup, each with four channels and separate digital trigger inputs. The SOFT3, delivered with the radar sensors, enables waveform visualization and storage as a .mat file.

Institute B is currently in the construction phase of the data acquisition system; only four functionalities are being used on the PC_M temporarily. VISU1 and DA1, VISU2, and DA2 correspond to data visualization and analysis models on different features and are utilized based on data analysts’ specific needs and heuristic decision-making (extension 2). Six analog input interfaces (ANAI) on ES2 are reserved for piezoelectric and oven temperature sensors that have not yet been selected and installed.

5.2 Data pipeline deployed for a metal wire punch-bending process (Institute C)

The system for metal wire forming consists of a test bed for quality inspection and two metal forming machines, i.e., a straightening machine and a punch-bending machine. With such a slim amount of hardware but complex connections, the intricate data flows need a transparent representation, which is identified as the main challenge for Institute C. The data flow view model (cf. Figure 5) fully highlights the effectiveness of the DSL4DPiFS. Additionally, the DSL is applied to support the development of a digital twin system for a punch-bending forming process [27]. The development of hardware and data analysis models is shown in the article, providing transparent insights about the digital-twins architecture to the different domain experts from metal forming technology and data analysis.

Figure 5:

Data flow view of the data pipeline in the metal wire punch-bending system covering extensions 1, 2, 4, 5.

The system mainly relies on an industrial computer (IPC) for process control and sensor activation (MC_*) to capture process data. Besides, two third-party industrial cameras are utilized for product shape inspection and offline quality inspection of product samples, whereby the data processing was supported by the corresponding third-party software (SOFT2 and SOFT3, extension 4). Data are also acquired from manual sampling and inspection of wire curvature (Wire_Photo_Curvature) using an industrial camera at the test bed (extension 2). As for the data analysis, the two feature extraction operations (extension 1) on PC_M are necessary steps for the corresponding models (Curvature_Analysis and Control_Analysis).

5.3 Data acquisition system for a multi-stage sheet metal forming process (Institute D)

In the multi-stage sheet metal forming system for deep drawing and cutting, 13 sensors, including third-party thickness measurement devices and profilometers, are installed on the field to acquire data for process control and quality optimization. At Institute D, the calibration of the individual sensors has different baselines and rules requiring particular attention, whose centralized display and management face challenges. Considering the diversity of hardware devices and their calibration rules, the hardware view of this use case is modeled with an omission of the machinery control part (cf. Figure 6).

Figure 6:

Hardware view of the data acquisition system for the multi-stage metal forming process covering extensions 3–5.

FireWire connects two third-party signal processors (extension 3) with I/O interfaces to synchronize the signal acquisition. A third-party software (SOFT1, extension 4) for utilizing data from the profilometer Profile_K is installed on the PC_M. The ReferenceID (extension 5) is sheet metal forming (=SFP) designation, +UID of the connected I/O device, followed by the sensor type (analog or digital), and the serial number (%SA* or %SD*). For example, the calibration of the thickness sensor =SFP+Thick_G%SA1 based on the reference workpiece needs to be performed every time before usage (RC1). For =SFP+SP1%SA1−4, load cells are used as point reference, while for =SFP+SP2%SA1, a specific material characteristic curve is used.

5.4 Evaluation results and expert feedback

The proposed five extensions appropriately address the collective requirements derived through the workshop series, which is well demonstrated by the modeling results of the three use cases. DSL4DPiFS addresses the main challenges in their respective use cases, namely the integration of essential information from a large number of different documents in Institute B, the representation of complex data flows based on a small number of hardware components in Institute C, and the centralized management of intricate calibration rules in Institute D. Experts from the three institutes agree that the DSL4DPiFS is a powerful modeling language that represents the data pipeline in metal forming systems intuitively and comprehensively. It can come in handy throughout the system lifecycle, including the initial design from scratch and the ongoing evolution phase.

On the one hand, it is possible to perform intensive analysis on individual models, e.g., system boundary conditions, local environmental constraints, usage of interfaces, etc. The benefits of such analysis may be concrete recommendations to improve system reliability and maintenance and potential directions for future improvement. Examples include the synchronization of data (for radar data of Institute B), the indicator-based sampling rule recognition (for the test bed of Institute C), and the automation of data transfer (for USB-based manual data transfer in Institute D).

On the other hand, this enables the clear comparison of different system design alternatives as models with standardized syntax on the table. More rational collective decisions can be made from the perspective of important information of interdisciplinary interest, such as the feasibility of introducing third-party hardware or software. Furthermore, validating the planned improvements by analyzing their impact is possible, as demonstrated in the three examples.

It is worth mentioning that the graphical model provides useful suggestions and hints for the refinement and optimization of data pipelines. In all three use cases, there are situations where a group of sensors measure the same physical quantity, which implies the specific requirement for data fusion or preprocessing at these positions.

During the evaluation, several newly identified challenges regarding using the DSL4DPiFS are also discussed as motivation for future improvements. For example, the Microsoft Visio-based template lacks user interactivity. Data analysts expect a more detailed representation of the models for data analysis, such as applied algorithms, data structures, batch sizes, etc., which are difficult to distinguish well by element “Sink, Source and Sink-source” currently, but particularly essential, especially when data pipelines become increasingly complex. Metal forming technologists suggest introducing information related to “process steps” to enable the mapping of complex metal forming process specifications to the generated data in the context of multi-stage or flexible manufacturing.