1 Introduction

Manufacturing (Mfg) is going through a disruptive change where mass-production automated systems are gradually replaced by models no longer coupled with itemized products. Integrated manufacturing evolves by adding new sensors, computing platforms, communication, and power supervisory systems. New concepts such as Cyber-Physical Systems (CPSs), twin systems, intensive modeling, Industrial Internet of Things (IIoT), and big data [1, 2] complete the transformation. Many of those changes affect directly the relationship between workers and the automated production lines [3], launching new design approaches [4,5,6,7,8]. The real challenge is anticipating requirements modeling’s formalization - especially if the target is an automated and service-oriented manufacturing (Mfg) process. In such cases, it is crucial to include a model for the coupling with customers in those formal requirements.

Process-oriented requirements engineering is the key to achieving a formal approach that includes customer coupling. Generically, the Requirements Engineering (RE) phase consists of eliciting, modeling, and verification steps. A formal presentation is not (conventionally) introduced in the modeling steps. In its turn, Intelligent Manufacturing requirements are dynamic; that is, they would actively influence the design, and after that, the implementation and deployment[9, 10] by providing support to maintenance. In our proposal, dynamical requirements are represented by invariants or background rationales.

This paper proposes a life cycle for requirements engineering applied to automated, intelligent manufacturing arrangements with the following characteristics:

  • Requirements are dynamic;

  • Requirements are formally modeled using language representations suitable to express the dynamic of automated problems, such as Petri Nets;

  • Requirements are formally analyzed and verified in each step of the cycle;

  • Requirements should include customer coupling;

  • Requirements should be the basis for innovation and maintenance, referring to requirements to include new features.

Petri Nets (PNs) emerged as a suitable and formal presentation to dynamic requirements [11]. Different Petri Nets proposals appeared since its proposition in 1962 until the appearance of the ISO/IEC 15.909 (www.iso.org /standard/67235.html) standard. The standard defines the basic types: Place / Transition, High Level, and Asymmetric nets (15.909-1). An interchange format PNML (Petri Net Markup Language) (15.909-2) may allow a formal model to be shared by different tools. User extensions (15.909-3) are accepted since they respect the formal definitions of 15.909-1. Extensions could be hierarchical nets, fusion places and transitions, gates, time, and object-oriented nets.

Therefore, it is encouraging to use Petri Nets as a formal presentation to requirements, fitting dynamic analysis and intelligent issues derived from draft models in diagrammatic (semi-formal) languages. UML is the most popular diagrammatic language (used in different project domains). Consequently, it is a suitable candidate to support new approaches for requirements analysis. Recent proposals have emerged, offering alternatives to functional development. The goal-oriented method is the most promising in this line[12].

Goal-oriented requirements engineering (GORE)emerged from the search for alternatives to strictly functional approaches [13]. It evolved to schematic presentations like KAOS [12]. Goal-oriented diagrams can be transferred to Petri Nets by specific algorithms. The authors of this paper developed a software tool called ReKPlan (Requirement Engineering in KAOS for Planning) to transfer KAOS diagrams automatically to Petri Nets [14].

The following section will show some basic concepts of Petri Nets and how we intend to use them to formalize the requirements of intelligent manufacturing systems modeled in UML. A small example of evaporator control will illustrate the process. Section 3 will discuss the proposed requirements life cycle using UML, followed by an alternative goal-oriented approach. A case study from Roadef Challenge, a Car Sequencing problem [14], will be reproduced to highlight these two different approaches’ differences. Section 5 will analyze the current context for manufacturing design and perspectives to match the proposed requirements life cycle with tools commercially available. Finally, Sect. 6 will show concluding remarks and perspectives on further work.

2 From draft to goal-oriented requirements

The requirements process’s efficiency could make the difference between success and failure in systems design [15], especially for automated system domains. The requirements cycle should deliver a consistent set of statements defining a closed vision of the problem, even if the description is not complete - we would call that a model. It should also be dynamic and guide the project’s evolution to implementation, including maintenance and final destruction. The term “dynamic requirements” has been used since the 50s, applied to different disciplines and domains with this same meaning[16]. More recently, with the prevalence of functional design, its use was reduced, particularly in automated systems. However, the emergence of service-oriented manufacturing and the demand for traceability brought back the need to reinforce dynamic requirements again [16]. The design of service systems (or product-service systems) demands recurrent checks for the satisfiability of requirements in different life cycle phases.

The early requirements phase must overcome two basic problems:

  • The genesys problem, which states that requirements are derived from intentions and distinct (and sometimes conflicting) viewpoints, which cannot be completely formalized;

  • The scope creep when emerging requirements affect the problem domain being used.

A requirement cycle that transfers diagrammatic and semi-formal representation into a formal language would face both problems. In this work, dynamic requirements should be represented by invariants, formalized using Petri Nets [17].

To face the genesys problem, we assume that the elicitation process starts by capturing intentions and demands (from different viewpoints) in clustered semi-formal diagrams. UML is a prominent example used in many object-oriented structured elicitation processes. It is used in this paper as a reference. That means to make the life cycle iterative proposal strictly a functional approach first, and then propose the evolution to other methods (as the goal-oriented).

The requirements life cycle proposed in this paper starts with a preliminary UML model initiating a cycle where each model is analyzed and formalized. Models express system dynamics by a state-transition (or Transition Systems) schema both in requirements and the solution. That means capturing semi-formal diagrams into Petri Nets [14, 17].

2.1 The Petri nets formalism

Petri Net was created in 1962 with Carl Adam Petri’s doctoral thesis, which focused on process management and communication between processes. With a hybrid background in Mathematics and Computer Science, Petri based his formalism on bipartite graphs and transitions systems - a key concept to computation theory. Such combination results in a sound formalism that is also executable, an important criterion to guide a formal presentation applied to Engineering Design. Formally[18],

Definition 1

(Petri Net) A Petri net structure is a directed weighted bipartite graph

$$\begin{aligned} N=(P,T,A,w) \end{aligned}$$

where

  • P is a finite set of places, \(P\ne \emptyset \)

  • T is a finite set of transitions, \(T\ne \emptyset \)

  • \(A\subseteq (P \times T)\cup (T \times P)\) is a set of arcs from places to transitions or from transitions to places

  • \(w:A\rightarrow \{1,2,3,\ldots \}\) is a mapping between the set of arcs and the positive integers.

We will normally represent a set of places by \(P=\{p_{1},p_{2},\ldots ,p_{n}\}\) and a set of transitions by \(T=\{t_{1},t_{2},\ldots ,t_{m}\}\), where \(\texttt {P}=n\) and \(\texttt {T}=m\) are the cardinality of the respective sets. A typical arc is an ordered pair \((p_{i}, t_{j})\) or \((t_{j}, p_{i})\), deppending on its direction. A mapping can associate a non-zero positive integer to its arc denoting a weight w, that is, the amount of tokens required to flow in the arc.

The authors developed a Petri Net modeling environment called GHENeSys (General Hierarchical Enhanced Net System) to model Place/Transition and High-Level NetsFootnote 1 following the standard ISO/IEC 15.909. A user extension introduces fusion places, inhibitor gates, hierarchy, and timed models. The hierarchical extension follows the Theory of Structured Programming [19]. Hierarchical elements are called macro-box and macro-activities and can be replaced by homogeneous sub-nets. Borders elements belong to the same type, either place or transition. We have then proper elements. These elements are said live if there is at least one path between two input and output border elements without deadlock. In other words, there is at least one free path leading from input to output. In this case, hierarchical levels preserve properties [18].

Definition 2

(Macro-place (transition)) A macro-place (transition) is a substitution place (transition) element [20] that can replace a place-bounded (transition-bounded) sub-net which is a proper entity [19], that is, there is only one input e one output element and at least one path between then without traps or deadlocks.

Definition 3

(Pseudo-boxes) A special place element, a pseudo-box, is a fusion place to match transfer signals provided by other sub-nets - reinforcing the structured approach - or external signals from the surrounding environment. Those signals are observed but not controlled by the system being modeled.

GHNeSys can be used for basic modeling and support formal verification (model checking) using Petri Nets and GHENeSys extension. Some of its essential elements are depicted in Fig. 1.

Fig. 1
figure 1

GHENeSys is a unified extensions to the basic Place/Transition and High-Level definitions, including elements as Pseudo-box - representing observable but not controllable events -, hierarchy and time

Full size image

In Fig. 1, Box and Activity are perfect matches to classic place and transitions, respectively, but accept hierarchical static (Macro-Box ) and dynamic (Macro-Activity) definitions. The Pseudo-Box is a fusion place that denotes the current sub-system’s connection with the application domain elements or other sub-systems. Arcs are a pictorial representation of the flux relation. Enabling Arcs are generally associated with Pseudo-Boxes and inserted without destroying the state equation. They are also helpful in expressing external connections.

2.2 Mapping UML to Petri nets

The number of articles dedicated to the translation of UML diagrams to Petri Nets increased significantly since the beginning of this century [21,22,23,24,25,26] due to the growing interest in formalizing the design process. Although different sets of UML diagrams have been used in the transfer, all share the idea of selecting a minimal set.

We improved Baresi classic algorithm for translation from UML to Petri Nets [21] in [17]. An illustrative (and realistic) example will show this translation using an extended set of diagrams: class, state, and activity translated to a Place/Transition net using GHENeSys. The example is based on an evaporator system controller’s specification, shown in Fig. 2.

Fig. 2
figure 2

Schema for the evaporator

Full size image

The evaporator system works according to the following (functional) description:

  • Tank 1 starts to be filled by opening valves V1 and V2;

  • Valves V1 e V2 are closed when Tank 1 is full;

  • The Mixer turned on;

  • After two time unit intervals, the Heater is turned on and actuates for 20 time units. The solution evaporates and is cooled in the Condenser.

  • The Heater is turned off;

  • The solution in Tank 1 is transferred to Tank 2 by opening valve V3;

  • The Mixer is turned off if Tank 1 is empty and valve V3 is closed;

  • The solution must remain in Tank 2 for 32 time units and then be liberated by opening valve V4.

  • Valve V4 is closed when tank T2 is empty, and the system returns to the initial state.

As established before, the functional approach is accurate but does not cover non-functional requirements. We might want to insert exception or failure possibilities modeled in a semi-formal language like UML.

Fig. 3
figure 3

State Diagram for the Controller

Full size image
Fig. 4
figure 4

UML Class Diagram for the Controller

Full size image

UML diagrams represent the controller’s intended behavior (requirements), including exceptions. State and class diagrams are shown in Figs. 3 and 4 respectivelyFootnote 2.

Briefly, let us suppose that the required initial conditions are not valid. Tank 1 is expected to be empty, V3 is closed, the system has no alarm set, and there is no indication of a malfunction in the mixer or the Heater. In that case, the sequence described above goes smoothly. Otherwise, the malfunction state is set, the alarm is turned on (if it is not on already), and when tanks T1 and T2 are empty, it is turned off and returns to the initial state.

Although the functional, intuitive description is purely sequential, there are parallel actions, as shown in the Petri Net representation.

Salmon et al. [17] proposed a UML-PetriNet translation algorithm, based on Baresi’s work [21]Footnote 3. The net resulting from this process is in Fig. 5. The diagrams of Figs. 3 and 4 were the input for this process.

Fig. 5
figure 5

Petri Net synthesized from UML diagrams for the Controller

Full size image

We are not going into details about the translation algorithm, but it is available in a previous work [17]. Requirements development based on UML/PN transference depends on the designer’s ability to capture non-functional requirements. However, it can synthesize dynamic requirements, that is, requirements that could be used as a reference during the whole design process up to deployment.

Table 1 shows some dynamic requirements, which justifies the use of Petri Nets formalization for the requirements modeling, providing an executable language presentation used in formal verification. OCL (Object Constraint Language) is also used to describe dynamic requirements [27]. In the proposed functional requirements development, OCL sentences complement functional requirements, adding constraints from the application domain, non-functional requirements, or invariants. The following section will present the life cycle based on a functional, object-oriented approach.

Table 1 Dynamic requirements for evaporation matched with Petri Nets invariants
Full size table

3 The requirements life cycle

The Petri Net in Fig. 5 was obtained by an algorithm [17], using a minimal set of UML diagrams. The transference composes the proposed functional requirement life cycle, depicted in Fig. 6.

The process starts with eliciting a set of requirements (from distinct viewpoints), checking for the generation gapFootnote 4, and generating a preliminary model. This semi-formal model (Fig. 6) is formalized by transferring it to Petri Nets. Property analysis over the formal model will check for invariant preservation, consistency, and closeness. Eventually, the requirements could be verified and matched with general (dynamic) requirements proposed in the definition of the project. A revision process will look for gaps that justify enhancing the requirement’s model, initiating another cycle. When no enhancement is feasible, the requirement specification is ready for documentation and to go forward in the design process.

The requirements cycle will be essential even in traditional product-oriented manufacturing automation. Nevertheless, it becomes more critical to design product-service systems (PSS)[28, 29]. Other formalization methods can be used to generalize the application domain, such as Event-B [30]. However, Petri Nets would better represent generic systems and process-oriented Model-Based Requirements Engineering (MBRE). Petri Nets can provide a formal state/transition approach where concurrency is analyzed and applied to distributed systems.

Appying the cycle (Fig. 6) to the evaporator control requirements (described by UML diagramas in Figs. 3 and 4), we transferred requirements to the Petri Nets shown in Fig. 5.

Of course, the practical use of the methods discussed here would require the requirement cycle’s encapsulation in a software tool that helps with process scaling and documentation. Features such as re-usability and version control are essential to achieve better results in practice. This paper intends to focus only on the method and its theoretical background. Still, we will discuss some ways to make it practical in the last section.

The requirements cycle in Fig. 6 relies on a cyclic refinement formal process that applies to functional and goal-oriented approaches. However, scaling that to large distributed production systems would bring some problems (supposing UML as the requirements presentation):

  • A demand to reduce redundancy and use a minimal set of diagrams;

  • Dealing with large packages of subsystems;

  • Including restrictions and conflicts between elements and subsystems;

  • Transferring hierarchical semi-formal presentation in UML to hierarchical Petri Nets.

Fig. 6
figure 6

The proposed requirements development cycle

Full size image

Therefore, there are enough reasons to look for alternative approaches to formalize the requirements process. A different approach is obtained using KAOS (a goal-oriented approach) as semi-formal presentation - which also is suitable to represent service-oriented manufacturing [4, 31].

4 Goal-oriented requirements engineering (GORE)

The increasing importance of requirements in systems design [15] encourages the search for alternatives to replace a strictly functional approach, both on software [32] and manufacturing [33] design. An alternative approach emerged based on goals, instead of functionalities [34]Footnote 5.

Goal-Oriented Requirements Engineering (GORE ) was formalized by John Myloupolos [35] and Axel Lamsweerde [12]. It inspired several works in requirements engineering. Focusing on goals instead of objects or functionalities, GORE postpones the concern with non-functional requirements, making requirements modeling more flexible and secure. However, GORE’s distinct advantage is the suitability to treat the coupling between system and users, making it more adherent to service-oriented design. This characteristic also points to GORE as a suitable approach to designing intelligent manufacturing systems [4, 6].

Visual modeling is covered in GORE by a semi-formal representation called KAOS. The following subsection will give a brief description of KAOS diagrams.

Fig. 7
figure 7

The general requirements life cycle and the introduction of Petri Nets to formal analysis

Full size image

4.1 KAOS diagrammatic representation

KAOS representation comprises four related (but not redundant) modeling diagrams: goal diagram, object diagram, operation diagram, and responsibility diagram. A goal diagram is a tree in which all nodes except the root represent related subgoals, and edges represent relations (such as composition, refinement, dependency, or restriction). Project statements are related to the main goal (the root). Fig. 7 shows the core elements of KAOS diagrams. (Fig. 8)

Fig. 8
figure 8

Main elements of Goal Diagram

Full size image

Goals should be achieved by requirements, which, in its turn, are associated with operations. Requirements should fit informal demands or expectations from specific users or stakeholders. Thus, it is possible to implicitly represent the merging of different viewpoints addressed by various agents’ classes attributing their respective responsibilities. That is the basis for traceability, which relies on invariants and dynamic requirements concepts.

Requirements modeling using KAOS or UML differs significantly from the approach directed to functionalities :

  • In the number of diagrams: four to KAOS, instead of thirteen structural and twelve behavior diagrams in UML. The diversity of diagrams encourages searching for methods to reduce it to a minimal set;

  • Using time in requirements analysis to schedule activities turn the functional approach a challenge [36];

  • Representing workflow is also an issue for manufacturing design, not fully assisted in UML or KAOS.

Linear Temporal Logic (LTL) is customarily used to formalize KAOS diagrams. However, the best way to put together logic-proof obligations, workflow, and eventually time constraints (or even real-time) is to use a widely formal graph representation, such as Petri Nets, capable of expressing concurrency and workflow and time extensions.

The following section will show an alternative requirements cycle replacing the semi-formal UML representation with KAOS. Algorithms already developed for some of the authors to transfer UML to Petri Nets [17] will be replaced by a new one (also developed by the authors) to transfer KAOS diagrams to Petri Nets.

4.2 Using Petri nets to analyze requirements

The proposed requirement cycle is process-oriented and selected Petri Nets as a formal approach since it is widely pointed to as suitable for this kind of application [37,38,39].

Petri Net is executable, which suits even better the requirement engineering process. A specific implementation of Petri Nets that follows the standard ISO/IEC 15.909 is used to formalize and verify requirements. The modeling platform is called GHENeSys (General Hierarchical Enhanced Net System) [18].

GHENeSys can work with classic P/T Nets or High-Level Nets as a unified net system. Extensions can also include hierarchy, time slice, time, and specific fusion places.

We propose an algorithm to transfer goal-oriented diagrams to classic or High-Level Petri Nets. Analysis and verification can then be performed, including invariant analysis. Invariants are defined during the initial requirements life cycle (RLC) or after semi-formal analysis and verification. Generally, emerging requirements are discovered during the net analysis and included in the requirements cycle.

Transfering KAOS to Petri Net implies a direct matching between diagrams and net regions. We propose a translation between a KAOS Markup Language (KML) and PNML - the XML description of Petri Nets. An algorithm based on heuristics [14] performs the transference from KML to PNML (Petri Net Markup Language)[40]. We will use a markup language associated with a unified extended Net GHENeSys (General Hierarchical Enhanced Net System) depicted in Fig. 9.

An illustration of a step in the requirements cycle using a goal-oriented approach is given in the next section using a problem proposed by the automotive industry.

Table 2 LTL sentences associated to some goals of Goal Diagram
Full size table

4.3 Case study: A car sequencing problem

General requirements for this problem are: the Car Assembling process must be flexible enough to fulfill particular and personalized demands elicited from final users [41] or to introduce requested items such as sunroof, customized wheels, air conditioning, or other similar items. Customer orders generally arrive at car factories in real-time and must be assigned to production with severe deadline constraints. A car sequence must be established daily, and its accuracy directly affects the amount and quality of cars delivered. (Nguyen, 2005) [42] shows a detailed description of demands for the production process.

The challenge is to propose a digital system that collaboratively controls the sequence lines using the requirements life cycle described in Fig. 6. We will use an alternative approach based on KAOS to capture requirements and transfer them to Petri Nets for formal analysis and verification. The transference between these representations is based on the match depicted in Fig. 9.

Fig. 9
figure 9

a Translation for basic elements. b Translation for refinements

Full size image
Fig. 10
figure 10

Goal Model for the Car Sequencing Problem using RekPlan tool

Full size image
Fig. 11
figure 11

Petri Net for Car Sequencing Problem

Full size image

We developed a software tool called ReKPlan (Requirement Knowledge for Planning) to capture goal and object diagrams. Figure 10 has a snapshot of ReKPlan tool [14].

Synthesis of Petri Net comes from KAOS, or LTL equationsFootnote 6. Table 2 shows the LTL expressions for the car sequencing problem. The Petri Net representation verifies properties such as closeness, consistency, deadlock, fairness, and invariants using the GHENeSys environment.

5 Perspectives for practical use of the requirements cycle

The requirements cycle of Fig. 6 (either using UML or KAOS development line) must be encapsulated in a software environment to become useful in real projects. We implemented RekPlan only to test basic features and reinforce the applicability of the requirement cycle. Additional features and integrated user experience are necessary to turn it into an environment and practical method. Some of these issues are:

  • Add database support to store semiformal requirements, linked to the respective formal representation: SysML, LTL, or Petri Nets;

  • Add knowledge-based support for reusability of modules or sub-systems;

  • Extends the formal approach to support real-time requirements and modelingFootnote 7;

  • Introduces version control and non-relational data structuring to extract better performance for traceability and check dynamic requirements (invariants);

  • Improves algorithms to automate the transference from semiformal representation (UML or KAOS) to Petri Nets;

  • Builds a design environment in the cloud, reinforcing collaborative work supported by data analysis.

Besides the practical aspects, a helpful system design tool for intelligent manufacturing should also cover the tendency to address Product-Service Systems (PSS), an ultimate goal for Industry 4.0.

5.1 Intelligent manufacturing as product-service systems

The idea of a symbiosis between product and service in a unique artifact appeared at the beginning of this century in works that pointed towards a way to insert sustainability in projects, especially in production lines [43]. Initially, the target was to introduce “service features,” called servitization, associated with vertical integration, combining manufacturing and business processes. This approach evolved into a product-service notion related to information systems and manufacturing resources planning (MRP) Architecture[44].

Service was a perfect match for information systems, and a Service-oriented Modeling Framework (SOMF) was proposed by Michael Bell [45]. The framework was fully implemented in the Enterprise Architect (www.sparx systems.com) platform and used to model requirements for new information systems. SOMF was extended later to deal with a broader concept of service (which would include manufacturing services) and implemented in the same Enterprise Architect platform (but not commercialized) [46].

The next challenge is to achieve a complete implementation of the product-service design, including a definition of the coupling with different classes of users (in a process called value co-creation) [4, 31]. This new environment should treat a large amount of data to be applied to intelligent manufacturing design [47].

Therefore, the current demand in intelligent manufacturing design is to address product-service systems (PSS) [29] in the requirements cycle. In the perspective of Industry 4.0 the target artifact is a vast network of cyber-physical arrangements [4], which information source could also rely on big data [47]. However, the first step to studying and building proper tools to implement PSS’s is formally exploring the requirements.

During the last decade, several software tools addressed the design of service-oriented systems: Enterprise Architect (Sparx) implemented SOMF, closely connected to information systems using a functional, object-oriented approach; a similar approach was used by Genesys (Vitech), using UML as semiformal and SysML as a formal presentation. However, these attempts did not cover the user’s inclusion in the modeling and design, neither the final user nor the worker [48].

A goal-oriented approach was implemented by Objectiver (Respect-IT), introducing LTL as a formal presentation. It was used in this work as a general goal-oriented environment to feed the process-oriented approach. Thus, our proposal is based on using different practical systems connected by a transfer language as KML (for KAOS), PNML (for Petri Nets)Footnote 8. The contribution is presenting the requirements development cycle based on a preliminary version of KML, presenting a practical tool to transfer requirements to Petri Nets: RekPlan. That could justify the goal-oriented as a feasible alternative to the functional approach in intelligent manufacturing.

PNML is used to transfer processes from RekPlan to Petri Net analysis tools as PIPE2, used in this work, to perform property analysis.

The transferrence algorithm from UML comes from a previous work of the same group [17]. It is inserted in the flexible cycle shown in Fig. 6. Scalability is still an issue, as it is for each tool we used, either commercial or academic. However, it applies to real problems, as shown in Fig. 11, even if not tested massively in manufacturing systems yet.

The critical point is that the proposal is prepared to face distributed production arrangements, can be evolved to service manufacturing, and include alternatives to the functional approach. Most importantly, it presents a clear formal development cycle for requirements, relying on invariants.

Another advantage is using Petri Nets as a formalism to intelligent manufacturing processes. Once Petri Nets typically represent processes in this area, it eliminates more transferrences from requirements to design.

6 Conclusion and further work

Systemic design of distributed intelligent manufacturing will demand formal approaches since the requirements phase, following a requirement life cycle, as depicted in Fig. 6. Different segments in the industry follow specific methods. Still, the growing complexity of manufacturing in technical organization and flexibility, besides the cloud’s directions, will reinforce a tendency to treat requirements formally.

UML modeling is the primary approach used in legacy projects from the academy and industry. Therefore, any new alternative must comply with this legacy. However, the functional approach presents some problems for large systems, including distributed arrangements and service orientation, demanding the search for new alternatives.

Choosing a proper formal approach suitable to represent requirements and design of processes became a key issue. Petri Net can deal with dynamic processes and concurrency and was proposed to compose a model-based requirements development. Each enhancement is properly formalized and analyzed before evolving. It suits a systematic approach and is used to each component sub-system and the general arrangement.

Another critical point is that new challenges in intelligent manufacturing point to distributed arrangements of cyber-physical systems (CpF) or cloud-based CpFs [49]. Thus, it is crucial to search for alternatives to cover this demand. Finally, it is also essential to attend to the service-oriented flavor of new manufacturing systems.

The development cycle presented here covers only the basic and alternative methods to formalize and analyze requirements. However, a cognitive approach modeling user and value co-creation [50, 51] for service manufacturing is being proposed as further work.

We are also worried about delivering a requirement engineering cycle that is usable and scalable to practical applications. Using different commercial and academic tools connected by a transferrence language based on XML we expect to reduce the time between new alternatives and their application.

Finally, we are developing a cloud-based environment to put together algorithms and tools already developed.