App settings:

Short Summary

This article describes the procedure for eliciting requirements in the form of use cases. In addition, the use of morphological matrices per use case is described. The resulting typification enables better handling of the complex overall topic. 



Goal and purpose

Without a requirements elicitation, however, we move disoriented in a labyrinth in which requirements are scattered. Without it, we do not obtain complete clarity and transparency of the requirements, no view of a common coherent content map. Particularly in IT projects with a wide variety of technological approaches, such as FabOS, requirements elicitation lays the foundation for discussion between the partners, structuring and joint alignment of the individual projects. 

The chosen method of use cases offers a number of advantages: They are easy to understand as well as relatively simple to create and compare using a uniform scheme.  

The description schema focuses on the representation of the user's view of a system. This understanding is relevant so that the future system fulfills its purpose in a very specific context and supports the system user in his tasks. All relevant scenarios that are of importance in the handling of a user task are specified. Concrete technical solutions are not described. 

For reasons of the large number of use cases created, these are each supplemented by a process-, data-, and technology-related typification based on a morphological matrix, which enables simple and quick content orientation in this use case landscape. 



The following approach was followed for FabOS 

Figure 1: Requirements elicitation process


Use case description - structure and summary 

@1 Uniform schema for the documentation of use cases 


Consistent description of use cases for FabOS requirements backlog. 


Definition of a uniform scheme for describing the content of a use case 


Uniform description scheme for FabOS use cases 


Figure 2: Description structure for use case


For further detail, user stories are added to the use cases as needed. 


@2 Description of the partner-specific use cases 


Description and summary of all use cases for FabOS requirements backlog. 


Description of the use cases by FabOS project partners 


Uniformly described use cases and summarized presentation of the provided use case descriptions 


Figure 3: Summary representation of the use cases 


Morphological matrix for characterization of use cases 

@3 Development of a morphological matrix to characterize the use cases 


Brief characterization of the use cases to identify similar use cases and to quickly convey the content focus and interrelationships of a use case 


Compilation of characteristics and characteristic values (incl. their definition) that sufficiently represent the FabOS subject context. 


Matched morphological matrix 


Figure 4: Features characterizing a use case 


Data and process-related features characterize the use case from a process and end-user perspective. 

Technology-related features characterize the use case in terms of which technological enablers are planned / necessary for this. 


@4 Charakterisierung der partnerspezifischen Anwendungsfälle 


Collection of the data-related, process-related and technology-related characterizations of all use cases 


Characterizations of the use cases by FabOS project partners 


Characterized use cases 


Figure 5: Example of data-, process- and technology-related characterization of a use case 


Comparison and evaluation of the provided short characterizations of the use cases. 

@5 Analysis and documentation of the use cases and their requirements 


Collection of the data-related, process-related and technology-related characterizations of all use cases 


Characterizations of the use cases by FabOS project partners 


Characterized use cases 


Figure 6: Cross-use case representation of process-, data-, and technology-related characteristic designations


Figure 7: Evaluation of the characteristic features of the use cases using the example of the process type: Processes for developing and planning products and production with regard to process- and data-related features. 


Summary of all results 

@ 6 Summary of functional and non-functional requirements 


Summary of the functional and non-functional requirements as well as the characterization of all use cases 


Creating deliverable 


Deliverable - systematically presented collection of requirements 



This paper describes the procedure for eliciting requirements in the form of use cases. In addition, the use of morphological matrices per use case is described. The resulting typification enables better handling of the complex overall topic.  


The result is a value-free characterization of the elaborated use cases that maps all relevant aspects regarding the process context, the data used and the enabling technologies for a comparative view. This provides the viewer with a quick orientation with regard to the process-, data- and technology-specific focal points in the use cases. 


Another goal was to enable the creator to express these morphological matrices for his use case as quickly and with as little effort as possible. 


Based on these morphological descriptions of the use cases, analyses can be performed on a process-type-specific basis (planning, production, logistics, supporting processes) and differences can be identified with regard to the use of data and the respective underlying technologies. 


Author: Jürgen Matthes

Firma: ASCon

Created by l.demes94 02.03.2022 09:1002.03.2022 09:10.

Modified by l.demes94 18.03.2022 10:0318.03.2022 10:03.

Short Summary

This article is about Open Source as driver for innovation in the domain of Industrie 4.0 and some important aspects of software licenses. 



Since the last century when computers first found their way onto shop floors, the basic concepts and computational paradigms used in industrial automation haven’t changed much. Most innovations have been confined to vendor-specific, proprietary ecosystems. With the advent of the internet and the digital economy, supply chains and markets did change and consequently industrial automation is in the midst of a transformational process, often characterized by the term Industrie 4.0. Relying on closed and proprietary environments may not be the best way to move forward with this transformation. In fact, it would limit the new production capabilities and business models that become possible with open and highly interconnected systems. Those who are first to recognize the benefits of open collaboration and innovation will gain a competitive advantage through the flexibility that results from open source platforms and participation in active ecosystems of collaboration. 


The platform economy is built on Open Source 

Platforms are central in today’s digital economy; in fact, seven out of the ten most valuable companies in the world are big players in the platform economy [1]. It is interesting to note that five out of ten of these companies are strong contributors to Open Source [2]. Unfortunately, none of them is European.  

We believe that the potential for European leadership in domains such as Industrial Automation, Robotics, and AI is highly connected to investments in Open Source Software and Open Collaboration. Open, industry-grade software platforms will allow organisations to collaborate on core technologies and compete on value-added products and services building on Open Source. Open Source enables Open Innovation and Open Collaboration and creates a huge opportunity to strengthen European leadership in Industrial Automation.  


Doing Open Source 

The definition of Open Source (OS) implies that source code is distributed under a license in which the copyright holders grant others the power to run, access, modify and re-distribute the software to anyone and for any purpose [3], thus enabling development under an open, collaborative model. Over the last decades, the Open Source Software (OSS) development model has gained more and more popularity around the globe. Nowadays, Open Source components are the core building blocks of application software in most innovative domains, providing developers with an ever-growing selection of off-the-shelf possibilities that they can use for assembling their products faster and more efficiently [4]. Whether you consume or contribute to open source, you need to have a sound knowledge of licensing and IP (Intellectual Property) management. If you are using Open Source in your commercial products, you will need to understand the license conditions of all the third-party libraries you are linking to. Things get even more complicated when contributing to Open Source projects or open sourcing a whole project. Depending on your business model you have to carefully consider which license is the best fit for your plans. 


The License Spectrum 

The license spectrum ranges from permissive licenses (e.g. MIT, BSD, Apache) to proprietary licenses which typically don’t allow modification or distribution of the software. 

In between, there are the “Copyleft Licenses”. In contrast to permissive licenses, these are considered protective or reciprocal as they impose more constraints on the users or integrators of the software. Within this share of the spectrum we find both strong (e.g. GPL, AGPL) and weak (e.g. EPL, MPL) copyleft licenses. Both allow free distribution and modification of the software. The devil is in the details: using strong copyleft licensed code usually forces you to put your own code under that same license whereas weak copyleft requires you to only publish changes to the original code under the original license [5].  

In other words, weak copyleft licenses allow free distribution and modification of the software (also in proprietary products) but require that changes made to the original code stay under the original license. Thus, weak copyleft licenses foster collaboration and innovation by ensuring that improvements to the open source project stay open while still allowing its use in your commercial product or providing added-value services on top. 


Open Source in FabOS 

The FabOS consortium is committed to contributing to an open Industry 4.0 ecosystem, i.e. a common platform that provides the infrastructure for AI-enabled industrial automation solutions and allows project partners to exploit this platform for their added-value applications and services.  




[3] The Open Source Definition (Annotated).” History of the OSI | Open Source Initiative,, 

[4] “The Ultimate Guide to Open Source Security.” WhiteSource, 



Author: Marco Jahn

Firma: Eclipse Foundation

Created by l.demes94 16.02.2022 08:4316.02.2022 08:43.

Modified by l.demes94 18.03.2022 10:0418.03.2022 10:04.

Short Summary

Autonomous production is enabled by data-driven technologies, partly in the form of AI. The autonomous capabilities of Cyber-Physical Production Systems (CPPS) are determined by their self-x capabilities. This article gives an overview of the self-x capabilities in CPPS and puts them into relation to defined levels of autonomy.



Cyber-physical production systems (CPPS) are CPS, which are applied in manufacturing environments to carry out production-related tasks. One of the first definitions of CPS has been framed by Lee, who defined CPS already in 2006 as integrations of computation with physical processes [1]. Embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa. This definition is still very much related to industrial control systems, but already reflects the networked nature of CPS components. With further technical progress, the definition of CPS also evolved further. The integrated research agenda Cyber-Physical Systems (agendaCPS) additionally puts emphasis on the global connectivity through the internet, societal impact, a partly autonomous nature, context awareness, and cross-domain applications of CPS, like medical applications, transportation, or smart buildings [2].


CPS underwent and still undergo a constant evolution partly driven by technological progress. The VDI has discussed the opportunities and benefits of CPS in automation based on the inherent nature and abilities of CPS [3] which goes beyond the definition of Lee [1] and Geisberger and Broy [2] and attributes additional capabilities regarding local intelligence to CPS. This emphasizes the autonomous nature based on the self-x capabilities of CPS needed to adapt to unforeseen environmental conditions and requirements, known as emergence. Also refined evaluation model is made available for CPS [4]. The model utilizes a set of system characteristics, which defines specific abilities and performance indicators. It is suitable for the characterization of cyber-physical technologies and thereby enabling a technological assessment.


Reference [5] provides a comprehensive survey on various concepts that affect the context and evolution of CPPS and lists robustness, autonomy, self-organization, self-maintenance, self-repair, or generally self-x among others as the expected capabilities of CPPS. These self-x capabilities of CPPS derive from the self-CHOP principles of the autonomic computing paradigm described by IBM. Originally self-CHOP encompassed the eponymic properties of self-configuration, self-healing, self-optimization, and self-protection [6]. Organic computing [7], which takes inspiration from the biological paradigm of self-organization of organisms, extends these primary self-x capabilities with self-explaining, respectively self-descriptive, abilities of systems and their components, but is not restricted to only these self-x properties.


A select analysis of the available CPS-centric literature allows a comprehensive overview of the essential self-x capabilities that should be provided by an ideal CPS [7]–[12]. These capabilities can be put in a hierarchy emphasizing the dependency of self-x capabilities building upon each other while growing in complexity as depicted in the following figure:


The self-x capabilities are grouped into functional blocks and ordered by increasing self-x complexity. The complexity and capabilities of the various self-x stages are progressively increasing while building upon each other. Self-x capabilities are directly related to autonomous features of systems. The working paper “Technology Scenario ‘Artificial Intelligence in Industrie 4.0’” is proposing five levels of autonomy for manufacturing systems [13]. This classification is inspired by the SAE  J3016 standard, which defines six levels of driving automation, going from Level Zero (no automation) to SAE Level 5 (full vehicle autonomy) with the human driver progressively transferring increasingly complex control tasks to the vehicle [14]. Similarly, a human operator will delegate more and more control and decision tasks to the machine in increasing autonomy levels.


Recent applications of autonomous systems are moving into level 2 and 3. Levels 4 and 5 are not yet attainable since the current data-driven technologies, respectively, AI algorithms, do not satisfy industrial requirements regarding safety and reliability. This is mainly caused due to the lack of explainability of AI algorithms [15].


According to [13], the levels of autonomy depicted in Fig. 1 for CPPS, can be described as follows:

•    Level 0 – No autonomy – human beings have full control without any assistance.

The ability to (formally) describe oneself using a defined language L.



•    Level 1 – Assistance with respect to select functions – human beings have full responsibility and make all decisions.

The basis for a more in-depth perception of one's state is to record and know one's state utilizing monitoring, which sets the state of one's system resources (reflection) in relation to the environment or other systems. For this purpose, the ability to diagnose and assess the consequences of an action is part of self-reflection. In this context, the ability to develop consciousness is also called self-reflection of self-reflections in connection with a system's ability to remember.



•    Level 2 – Partial autonomy in clearly defined areas – human beings have full responsibility and define (some) goals.

Self-control and self-regulation, because of a recognized necessary action, is primarily responsible for ensuring that the system can maintain a stable state. The ability to self-configure provides the scope of action in which self-regulation is possible.



•    Level 3 – Delimited autonomy in larger sub-areas – system warns if problems occur, human beings confirm solutions recommended by the system or functions at a fallback level.

The ability of self-adaptation serves to achieve an optimal operating state (self-optimization) under continually changing conditions and requirements employing self-generated instructions for action. The optimum state can also be improved system-wide or locally. By acquiring new information or capabilities, the system can continuously go through an evolutionary process by which it provides itself with new capabilities.



•    Level 4 – System functions autonomously and adaptively within defined boundaries – human beings can supervise or intervene in emergency situations.

The self-protection of a system is the ability to arm itself against threats or adverse effects that did not exist during the design. To this end, the system uses self-servicing, self-healing, or self-repair to restore or prevent individual system components or their connection to each other in the event of unexpected disruption or failure.



•    Level 5 – Autonomous functions in all areas including in fluctuating system boundaries – human beings need not be present.

The self-organization of a system is the ability to alter its internal structure without being influenced by external control elements. This mainly serves to counteract emergence effects, i.e., the occurrence of unforeseen interactions of complex systems. External influences are possible but are considered on a higher level, which reduces the internal complexity of the system to the outside, and only steering influences are allowed.

Finally, and beyond the defined autonomy levels is the ability for replication and reproduction. Self-replication or self-reproduction is the ability to duplicate oneself or individual system components. A system which goes beyond the stages of autonomy is currently not achievable and would possible meet requirements the requirements of the technological singularity, which is a hypothetical point in time at which technological growth becomes uncontrollable and irreversible. According to the most popular version of the singularity hypothesis, called intelligence explosion, an upgradable intelligent agent will eventually enter a "runaway reaction" of self-improvement cycles, each new and more intelligent generation appearing more and more rapidly, causing an "explosion" in intelligence and resulting in a powerful superintelligence that qualitatively far surpasses all human intelligence [16].


[1]    E. A. Lee, “Cyber-Physical Systems - Are Computing Foundations Adequate?,” presented at the NSF Workshop On Cyber-Physical Systems:Research Motivation, Techniques and Roadmap, 2006.
[2]    E. Geisberger and M. Broy, “Living in a networked world - Integrated research agenda Cyber-Physical Systems (agendaCPS),” acatech - Deutsche Akademie der Technikwissenschaften e. V., Berlin, 2015.
[3]    K. D. Bettenhausen and S. Kowalewski, “Cyber-Physical Systems: Opportunities and Benefits from the Viewpoint of Automation,” VDI - The Association of German Engineers, Düsseldorf, 2013.
[4]    M. Weyrich, M. Klein, J.-P. Schmidt, N. Jazdi, K. D. Bettenhausen, et al., “Evaluation model for assessment of cyber-physical production systems,” Industrial internet of, 2017.
[5]    L. Monostori, “Cyber-physical production systems: roots from manufacturing science and technology,” at - Automatisierungstechnik, vol. 63, no. 10, Jan. 2015.
[6]    P. Lalanda, J. A. McCann, and A. Diaconescu, Autonomic Computing: Principles, Design and Implementation. London: Springer, 2013.
[7]    R. P. Würtz, Organic Computing. Berlin, Heidelberg: Springer, 2008.
[8]    S. Jeschke, C. Brecher, H. Song, and D. B. Rawat, Eds., Industrial Internet of Things: Cybermanufacturing Systems. Cham: Springer, 2017.
[9]    D. Burmeister, B. Gerlach, and A. Schrader, “Formal Definition of the Smart Object Matching Problem,” Procedia Comput. Sci., vol. 130, pp. 302–309, Jan. 2018.
[10]    L. Gurgen, O. Gunalp, Y. Benazzouz, and M. Gallissot, “Self-aware cyber-physical systems and applications in smart buildings and cities,” in 2013 Design, Automation Test in Europe Conference Exhibition (DATE), 2013, pp. 1149–1154.
[11]    J. Bakakeu, F. Schäfer, J. Bauer, M. Michl, and J. Franke, “Building Cyber-Physical Systems - A Smart Building Use Case,” in Smart Cities, vol. 10, H. Song, R. Srinivasan, T. Sookoor, and S. Jeschke, Eds. Hoboken, NJ, USA: John Wiley & Sons, Inc., 2017, pp. 605–639.
[12]    L. Monostori, B. Kádár, T. Bauernhansl, S. Kondoh, S. Kumara, et al., “Cyber-physical systems in manufacturing,” CIRP Annals - Manufacturing Technology, vol. 65, no. 2, pp. 621–641, Jan. 2016.
[13]    K. Ahlborn, G. Bachmann, F. Biegel, J. Bienert, S. Falk, et al., “Technology Scenario ‘Artificial Intelligence in Industrie 4.0,’” Bundesministerium für Wirtschaft und Energie (BMWi), Berlin, 2019.
[14]    On-Road Automated Driving (ORAD) committee, “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,” SAE International, 400 Commonwealth Drive, Warrendale, PA, United States, Jun. 2018.
[15]    B. Kosch, M. Heintel, D. Houdeau, W. Klasen, M. Ruppert, et al., “Handling security risks in industrial applications due to lack of explainability of AI results,” Federal Ministry for Economic Affairs and Energy (BMWi), 2019.



Author: Daniel Stock

Firma: Fraunhofer IPA 

Created by l.demes94 02.02.2022 09:1202.02.2022 09:12.

Modified by l.demes94 18.03.2022 10:0118.03.2022 10:01.