Demonstrators for Industrial Cyber-Physical System Research: A Requirements Hierarchy Driven by Software-Intensive Design

TL;DR

The paper tackles the ambiguity around demonstrators in research projects and argues that TRL alone is insufficient for planning multi-WP, industry-collaborative efforts in software-intensive industrial CPS. It introduces a five-level demonstrator taxonomy and a seven-block requirements-elaboration framework that integrates TRL targets, artefact readiness, and WP dependencies, underpinned by adapted TRLs for SIS. Through case studies of ZORRO and PrimaVera, the authors show how early application of the framework exposes misalignments and guides requirement specification to enable more feasible, integrated demonstrations. The approach aims to improve stakeholder alignment, planning accuracy, and progress tracking in complex, software-centric CPS research, with prospects for automation and broader artefact-quality assessment in future work.

Abstract

One of the challenges apparent in the organisation of research projects is the uncertainties around the subject of demonstrators. A precise and detailed elicitation of the coverage for project demonstrators is often an afterthought and not sufficiently detailed during proposal writing. This practice leads to continuous confusion and a mismatch between targeted and achievable demonstration of results, hindering progress. The reliance on the TRL scale as a loose descriptor does not help either. We propose a demonstrator requirements elaboration framework aiming to evaluate the feasibility of targeted demonstrations, making realistic adjustments, and assist in describing requirements. In doing so, we define 5 hierarchical levels of demonstration, clearly connected to expectations, e.g., work package interaction, and also connected to the project's industrial use-cases. The considered application scope in this paper is the domain of software-intensive systems and industrial cyber-physical systems. A complete validation is not accessible, as it would require application of our framework at the start of a project and observing the results at the end, taking 4-5 years. Nonetheless, we have applied it to two research projects from our portfolio, one at the early and another at the final stages, revealing its effectiveness.

Figures (5)

• Figure 1: WP dependency diagram for the ZORRO project, covering direct dependencies with solid and uncertain/undefined demonstration WP input with dashed arrows.
• Figure 2: Visualising the coverage scope per different demonstrator level descriptions: Functional and extra-functional requirements (white and green blocks); Level 1 proof of concept (blue box); Level 2 proof of integration (red area); Level 3 optimised proof of integration (magenta box).
• Figure 3: Visualising the project-wide view, covering all interacting WPs and in this case, an island WP: Functional and extra-functional requirements within any particular WP (white and green blocks); Level 1 proof of concept (blue boxes); Level 4 grand proof of integration (red area); Level 5 optimised grand proof of integration (magenta box).
• Figure 4: The demonstrator requirements elaboration framework is depicted. The diagram covers 7 steps with relevant processing, sources, as well as relations amongst these. Blue arrows are feedbacks to previous steps, green arrows are input from sources, and black arrows represent the sequential progression of blocks.
• Figure 5: WP dependency diagram for the PrimaVera project, covering direct dependencies with solid arrows and input to the demonstration WP with dashed arrows.