## 3 A SOA-Based Engineering Process Model
### The Arrowhead-EP Model and the Execution of a Real EP  
The model is implemented with an ontology that, instantiated for a specific Arrowhead-EP, provides all the details related to the EP coverage, adopted tool-chains and tools, connections between EPPs, tool-chains, and tool dependencies. The model is also supported by a tabular format that simplifies the visualisation of the Arrowhead-EP and, according to the ontology described in Section 3.3, can be encoded in a standard way by adopting a simple table or in a more structured way using specific modelling languages. The adoption of system modelling languages, such as SySML, potentially makes complex multistakeholder EPs simpler to model, control, and extend, while simplifying their practical management, and improves the efficiency, flexibility, and scalability of the modelling process. Moreover, system modelling languages promote the adoption of machine-supported engineering and autonomous engineering, which play a key role in the future evolution of engineering process automation. Starting from the ontology of a specific Arrowhead-EP, a service-oriented framework allows the management of the Arrowhead-EP and facilitates its automation. For this purpose, we select the _Eclipse Arrowhead framework (EAf)_[58], which, with a service-oriented architecture (focused on microservice support), simplifies the creation and management of the links and dependencies between tool-chains/tools, provides security and authentication support, and facilitates the integration, automation and practical management of the Arrowhead-EP in real use cases. In the _Eclipse Arrowhead framework_, the Engineering Process Management System (EPMS) is the new component in charge of managing the Arrowhead-EP. The EPMS (Figure 7) acts as a scheduler and orchestrator of the EP and is required to monitor the ongoing activities to ensure that the dependencies between phases, stakeholders, tool-chains and tools are respected. Moreover, EPMS is responsible for scheduling and controlling sequential and concurrent EP activities and managing tool inputs and outputs. Due to the SOA/microservice architecture of the _Eclipse Arrowhead framework_, the EPMS can be implemented by adopting a scheduler already available on the market or extending some _Eclipse Arrowhead framework (EAf)_ services currently under development [59]. The EPMS will be the subject of future works. Figure 7: Example of the single-stakeholder Arrowhead-EP architecture based on the _Eclipse Arrowhead framework_ (blue and red arrows represent the information flow). To provide these functionalities, the EPMS needs an _Arrowhead-EP description_ (Figure 5), which is the use case engineering process schema designed with the ontology of a specific Arrowhead-EP and with the related VCEP-Map. The EPMS models the EPPs as services. Each EPP generating outputs is represented by a service that publishes data in the _Eclipse Arrowhead framework_, while every EPP requiring an input is represented by a service that consumes data from one or more _EAf_ services published by other EPPs and belongs to the same Arrowhead-EP or to other EPs in the case of a multistakeholder use case. The EPP services require three parameters: the ID of the Arrowhead-EP, the ID of the tool producing and consuming data/EP-metadata, and the produced and consumed data/EP-metadata (or a pointer to it). Tools composing the tool chains call the services to provide and consume information. Tools not supporting the _Eclipse Arrowhead framework_, such as proprietary or legacy tools that cannot be upgraded with _EAf_ support, can interact with _EAf services_ through a specific _EAf Adapter_ (e.g., phases 3-5-7 in Figure 5). On the one hand, the _EAf Adapter_ interfaces directly with the tool native interface to obtain or provide data; on the other hand, it calls the _EAf services_ simulating an _EAf_ native tool. Eventually, tools can provide _EAf services_ natively or through an adapter, which allows the EPMS to control them.