## 3 A SOA-Based Engineering Process Model
### The Arrowhead-EP Concepts and Rules  
We designed the Arrowhead-EP ontology to manage the complexity of the engineering process of Industry 4.0 use cases developed with an SoS paradigm. The ontology was conceived to track the interactions between the engineering process's phases, tool chains, and related tools, especially considering the EPs adopted in the multistakeholder value chains. The structure of the Arrowhead-EP model (Figure 3) is based on _Engineering Process Units (EPIs)_, which are classified as follows: (i) _Engineering Process Phase (EPP)_, the eight phases described in the previous section; (ii) _Engineering Process Interface (EPI)_, which represents both the input (_EP-I[n]_) and the output (_EP-O[n]_) connections between the internal Arrowhead-EPPs and the external phases of other EPs adopted by different stakeholders involved in the system value chain. Moreover, we introduce the _Engineering Process Connection (EPC)_, which is an enumeration system adopted to assign a unique identifier to each EPI connection (a pair of interfaces). Depending on the nature of the EPI connection, specific agreements between stakeholders define who the stakeholder is responsible for when implementing the connection. In Figure 3, _EP-O1_ is an EPU that represents an output of the _Requirements_ EPP, while _EP-I7_ EPU represents an input for the _Evolution_ phase. To enumerate the multiple EP-I/EP-O of a single EPP, we adopt the following rule: in the case of multiple EP-I, we begin by assigning a letter to each interface in clockwise order, starting from the input on the bottom left; in the case of multiple EP-O, we start the enumeration from the output of the EPP placed on the right-top side of the block. The Arrowhead-EP ontology also introduces the _Engineering Process Mapping (EPM)_ designed to identify the links between the tools and one or more EPUs. The Arrowhead-EP of an IoT- or an SoS-based use case can be designed by connecting the EPPs in a custom flow graph, following the specific sequence of phases of the EP adopted in the use case and without necessarily adopting the sequential order illustrated in Figure 3.  
Figure 4 provides an example of a use case where two Arrowhead-EPs and an unknown EP adopted by three different stakeholders (StkHs) are connected and cooperate to design, develop, and operate a system. The dashed lines represent external EP connections between different Arrowhead-EPs and/or unknown EPs. In this example, Arrowhead-EP StkH-1 is the main EP that adopts seven of the eight Arrowhead-EP phases (the _Evolution_ phase is not used) and is connected with two external EPs: the Arrowhead-EP2 from stakeholder 2 and the External EP from stakeholder 3. Arrowhead-EP 2 is composed of three EPPs, where two (EPP1 and EPP4) are externally connected with EPP2 and EPP3 of Arrowhead-EP 1, respectively. The External EP, represented as a black box because the internal structure is unknown, receives inputs from EPP6 of Arrowhead-EP 1 and provides inputs in EPP3. It is the responsibility of the stakeholder adopting a specific EP to implement and validate the interfaces and connections belonging to the perimeter of the adopted EP (represented as coloured borders in the Figure 4 example). Additionally, in the example, stakeholder 1 (StkH-1) is responsible for implementing and validating all the connections enumerated from _c1_ to _c12_, while StkH-2 is responsible for _c13_ and _c14_. One important advantage of the Arrowhead-EP model is that the structure of the interconnections between the phases and stakeholders can change over time, following the evolution of the various system versions to be designed, developed, and operated. The adoption of a service-oriented approach facilitates the evolution of the Arrowhead-EP in terms of stakeholders, technologies, system components, tool chains and tools.