Melisande Blein-Nicolas
email: melisande.blein-nicolas@inra.fr

Sandra Negro

Thierry Balliau

Claude Welcker

Llorenç Cabrera-Bosquet

Stephane Nicolas

Alain Charcosset

Michel Zivy

L Cabrera

H Corti

F Tardieu

Genome wide association study for protein expression under normal and water deficit conditions in maize leaves

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

GWAS was performed for 3900 molecular phenotypes (1950 proteins x 2 environments). A total of 27151 pQTLs were dected for 95% of the molecular phenotypes (13716 in WD;13435 in WW). Less than 10% of the pQTLs were conserved between the two environments, indicating that water deficit has deeply impacted the regulation of protein expression (Fig. 3).

Water deficit has deeply impacted regulation of protein expression

Co-regulation networks are partially preserved between environments A total of 1950 proteins were quantified in the two watering conditions (973 by XIC, 977 by peak counting). Of them, 70% responded significantly to water deficit indicating that environmental change deeply impacted the proteome (Fig. 2). Maize is one of the main crops worldwide (160 Mha, 753 Mt/year). But its yield can be severely affected by drought, particularly at flowering. Drought tolerance in maize is genotype-dependent, indicating that this trait can be genetically improved. To decipher the molecular basis for drought tolerance, we used a systems genetics approach whereby causal variants of traits of interest and their molecular effects were inferred through integration of genomic data with proteomic data in a context of natural diversity (Fig. 1). Analyzing a thousand samples in proteomics: it is doable! Nearly 2000 proteins were quantified, hundreds of them were affected by mild water decit and many of them showed genetically variable responses. pQTLs were detected for most proteins confirming the high genetic variability of their abundances. Altogether, these results show the potential of high-throughput quantitative proteomics to decipher the determinisms of protein abundance regulation and to discover candidate genes and proteins potentially involved in the variation of plant phenotypic traits.

Co-expression networks were build from protein abundances in each environment, showing that stress proteins were co-expressed specifically under WD. In both environments, modules correlated to traits of interest were identified (Fig. 4).

Genomic regions controlling the abundances of more than 20 proteins were identified, representing potential hotspots of regulation. Several of these regions colocalized with QTL for co-expression modules indicating that the proteins within these modules are co-regulated. Regions controlling the abundance of ribomal proteins were detected in both environments. These regions were not the same in the two conditions indicating that regulation of translation is affected by water deficit (Fig. 5).

Fig 2 :

 2 Fig 2: Heatmap representation of protein abundances showing that theroteome was deeply remodeled in response to water deficit. Each line corresponds to a protein and each column to a genotype x environment combination. For each protein, abundance values were scaled and represented by a color code as indicated by the color-key bar

Fig. 4 :

 4 Fig. 4: Representation of the co-expression networks in WW (A) and WW (B). Several modules were significantly enriched for specific functional categories. Modules positively or negatively correlated to plant phenotypes such are biomass or leaf area are indicared by plain and dotted circles.

Fig. 1 :Fig

 1 Fig. 1: Schematic representation of the systems genetics approach


B Bézard

A Fedorova

J.-L Bertaux

A Rodin

O Korablev

The 1.10-and 1.18-µm nightside windows of Venus observed by SPICAV-IR aboard Venus Express

Introduction

Thermal emission from the deep atmosphere of Venus observed on the night side in the 1.10-and 1.18-µm windows provides information on the water vapor abundance in the altitude range 0-25 km. The H 2 O mole fraction near the surface is still controversial and the various analyses of in situ measurements and observations of the nightside windows do not yield consistent results [START_REF] Bézard | Water vapor abundance near the surface of Venus from Venus Express/VIRTIS observations[END_REF]. We present here an analysis of the 1.10-and 1.18-µm nightside windows observed by the infrared channel of the SPICAV (Spectroscopy for the investigation of the characteristics of the atmosphere of Venus) instrument aboard Venus Express [START_REF] Bertaux | and 35 colleagues: SPICAV on Venus Express: Three spectrometers to study the global structure and composition of the Venus atmosphere[END_REF]. We investigated the influence of the various sources of opacity (CO 2 and H 2 O linelists, CO 2 far wing and "continuum" opacity) on the spectrum and of the associated uncertainties or unknowns. The results were used to propose a best representation of the CO 2 and H 2 O opacity and to derive a best fit H 2 O mixing ratio.

Observations

We used nadir observations by the LW range of the visible-infrared channel (Vis-IR) of SPICAV, a single pixel spectrometer based on AOTF technology [START_REF] Bertaux | and 35 colleagues: SPICAV on Venus Express: Three spectrometers to study the global structure and composition of the Venus atmosphere[END_REF]. The spectral resolution is about 5.2 cm -1 (0.7 nm at 1.18 µm) . We made a large average of LW spectra recorded during Orbits 800 and 825, yielding a S/N ratio of 500 at the peak of the 1.18-µm window (Fig. 1).

Spectral modelling

Synthetic spectra were generated using a line-by-line radiative transfer model with scattering [START_REF] Bézard | Water vapor abundance near the surface of Venus from Venus Express/VIRTIS observations[END_REF] and compared with the SPICAV selection. We allowed the use of a constant scaling factor as a free parameter to account for the unknown cloud optical depth.

We first investigated the CO 2 far wing lineshape, which is constrained by the high-wavelength wing of the 1.18-µm window. We found that the line profile model of Afanasenko and Rodin [START_REF] Afanasenko | Interference of spectral lines in thermal radiation from the lower atmosphere of Venus[END_REF] underestimates the CO 2 absorption and we derived instead an empirical sub-lorentzian profile that reproduces this wing. It provides more absorption than those previously derived for CO 2 bands near 2.3 µm at room temperature.

The variation of the 1.10-and 1.185-µm radiance with surface elevation, as observed by the Venus Express / VIRTIS-M instrument, requires an additional "continuum" opacity, besides that provided by the CO 2 and H 2 O allowed bands. We have re-analyzed the dataset of Bézard et al. [START_REF] Bézard | Water vapor abundance near the surface of Venus from Venus Express/VIRTIS observations[END_REF] to constrain this additional absorption at 1.10 and 1.185 µm and derived a constant absorption coefficient, equal to 0.7 ± 0.2 × 10 -9 cm -1 amagat -2 .

We have modeled the SPICAV spectra using either the high-T [START_REF] Pollack | and 11 colleagues: Near-infrared light from Venus' nightside: A spectroscopic analysis[END_REF] or CDSD [START_REF] Rothman | and 8 colleagues: HITEMP, the hightemperature molecular spectroscopic database[END_REF] CO 2 line lists. The latter provides less absorption than "High-T" in the interval 1110-1190 nm and reproduces worse the observed spectrum, due to the absence of the 5ν 1 +ν 3 series of CO 2 bands. On the other hand, CDSD agrees better with the observations shortward of 1100 nm although the data clearly show evidence for a missing absorption between 1085 and 1100 nm. In this work, we have used a composite CO 2 line list combining "High-T" and CDSD.

Absorption by HDO had not been previously added in the modeling of the 1.10-and 1.18-µm windows. Using a recently published line list (VTT) [START_REF] Voronin | A high accuracy computed line list for the HDO molecule[END_REF], we found that the influence of HDO is significant in the range 1140-1190 nm, inducing a 7% drop in radiance at 1185 nm and slightly improving the fit of the SPICAV spectrum. We also confirm that the H 2 16 O BT2 database [START_REF] Rothman | and 8 colleagues: HITEMP, the hightemperature molecular spectroscopic database[END_REF] yields more opacity than the GEISA or HITRAN databases, being more accurate and more complete in high-energy lines [START_REF] Bailey | A comparison of water vapor line parameters for modeling the Venus deep atmosphere[END_REF].

Using the sources of atmospheric opacity described above, we determined a best-fit value for the H 2 O mole fraction of 30 !5 +10 ppm (assumed constant below the clouds) (Fig. 1). The emission in the H 2 O band is most sensitive to the region 5-25 km.

Discussion and conclusion

We have used observations of the night side of Venus by the Venus Express / SPICAV-IR instrument in the 1.10-and 1.18-µm windows to better characterize the various sources of molecular opacity at these wavelengths and determine the average mole fraction of water vapor in the 5-25 km altitude range.

The 30-ppm mole fraction we derived is smaller that that derived from VIRTIS-M spectra (44 ± 9 ppm) [START_REF] Bézard | Water vapor abundance near the surface of Venus from Venus Express/VIRTIS observations[END_REF], even though the error bars overlap. This value is fully consistent with the mole fraction derived at 30-45 km from the 2.3-µm window and at 15-25 km from the 1.74-µm window. This result gives strong evidence that the water mole fraction is constant from approximately 5 to 40 km, as predicted by chemical models.

Our best fit model still shows some discrepancies with the SPICAV spectrum, e.g. between 1085 and 1100 nm. They likely result from an inaccurate representation of the CO 2 opacity. Laboratory measurements would help in this regard.

Figure 1 :

 1 Figure 1: The SPICAV spectrum is compared to synthetic spectra calculated with H 2 O mole fractions of 20, 30 and 45 ppm using our best estimate for the representation of the H 2 O/HDO and CO 2 opacity. Upper panel: raw calculations; Lower panel: spectra renormalized to the observed radiance at 1185 nm.

Acknowledgements

We are grateful to V. Perevalov and A. Campargue for extremely useful discussions on the CDSD databank and for providing positions and relative intensities of the 5ν 1 +ν 3 CO 2 bands. We thank J. Bailey for providing useful information on the water vapor databases. B.B and J.-L.B. acknowledge support from CNES and CNRS. A.F., A.R., and O.K. acknowledge RFBR grants 10-02-93116 and 08-02-01383.


Joseph Rahme

Bharat Masimukku

Nicolas Daclin

Gregory Zacharewicz
email: gregory.zacharewicz@mines-ales.fr

Pedro Pereira

Luis Gomes

João Goes

Improving ERPs Integration in Organization: An EOS-Based GreneOS Implementation

Keywords: enterprise operating systems (EOS), architecture, infrastructure, interoperability, enterprise operations, workflow, Archimate

Current ERPs are still limited by cost, customization, implementation time, and interoperability with other systems. Even if cloud-based ERPs attempt to overcome these limits, they do not completely answer all of them. Based on that postulate about recent ERPs, a conceptual architecture, technical architecture, and implementation architecture of an Enterprise Operating System (EOS) have been designed and proposed to address the services and functionality needed by Enterprise 4.0. This conceptual architecture describes the essential functions required in the EOS, while the technical architecture shows how these tasks cooperate to achieve the mission of the EOS. Among some implementation architectures proposed that benefited from the innovation and concept of the EOS, GreneOS has proposed a technical architecture motivated by EOS concepts. The purpose of this paper is to discuss the current interest, complementarity, and limitation of both the EOS conceptual architecture and its implementation into Gre-neOS to propose perspectives for the future developments of the EOS.

Introduction and Problem Statement

In previous works, the conceptual, technical, and implementation architectures of an Enterprise Operating System (EOS) have been designed to meet the services and functionalities recognized in the foundation paper [START_REF] Youssef | Enterprise Operating Systems[END_REF][START_REF] Youssef | Developing and Enterprise Operating System (EOS) with the Federated Interoperability Approach[END_REF]. The conceptual architecture described what core functions are required in the EOS, while the technical architecture showed how these implemented functions can cooperate to achieve the EOS mission. A first implementation architecture has been proposed to test the EOS innovation and concepts in a technical architecture based on Java HLA [START_REF] Youssef | Developing an Enterprise Operating System (EOS)-Requirements and Architecture[END_REF]. Meanwhile, GreneOS proposed another technical architecture inspired as well by the concepts of the EOS. The goal of this paper is to describe the process from concepts to implementation, providing the interest and current limits of the approach to propose perspectives for the further developments of the EOS.

For enterprises, ERP systems integrate organizations' applications at the informational and operational level to utilize and automate many back-office functions related to technology and information services by collecting, storing, managing, and interpreting business activity data. Over the years, these ERP systems offer increasingly improved enterprise application integration by providing the most integrated suite of applications to perform standard business functions [START_REF] Burnson | Enterprise Resource Planning Software-Buyer Report[END_REF]. At its most basic level, ERP software integrates these various functions into one complete system to streamline processes and information across the entire organization. The central feature of all ERP systems is a shared database that supports multiple functions used by different business units. Today, traditional on-premises ERP systems are gradually being eclipsed by the growing demand for cloud-based ERP systems [START_REF] Ahmad | Strategy and procedures for Migration to the Cloud Computing[END_REF] due to their lower costs and faster deployment. In this migration to cloud technology, the impact of the pervasive digital transformation of businesses is a true challenge. The ERP module is basically presented as a black-box application implicating built-in services and modules. It does not ensure an efficient integration between its built-in applications [START_REF] Guerola-Navarro | Customer relationship management and its impact on innovation: A Lit[END_REF].

Nevertheless, the current state of the art of ERP reports that interconnectivity (and interoperability) barriers remain between departments despite the use of advanced ERPs [START_REF] Chang | Delphi examination of public sector ERP implementation issues[END_REF]. These interoperability barriers within an enterprise unit or department lead to limitations in communication with other departments. If a department encounters these limits, it can affect the overall efficiency of the enterprise. It is therefore important to choose an environment and a system that overcomes the interoperability barriers, and which will optimize the company as a whole and improve its efficiency.

Furthermore, the cost of an ERP remains high, and they are identified for some SMEs as too expensive of a system. Enormous upfront costs and per-user licensing is the biggest challenge with traditional enterprise resource planning systems. However, there are another unseen and scarier disadvantage in terms of:



Data: the limited number of users on the platform results in incomplete, broken data and the loss of data precision.



Culture adaptation: Every enterprise has its own culture, and this is most seen in its data, processes, and decisions, while the Degree of Customization is still extremely limited for strategic and technical orientation reasons.



Integration: Enterprises today are bombarded with an array of applications for different processes, yet all of them at their core are incompatible with each other, resulting in data silos, lengthy workflows, and slow decisions based on legacy data. In addition, it is not possible to extract the business process model to go to simulation. The ERP module is presented as a black-box application implicating built-in services and modules which may not allow to master the efficient integration between its built-in applications and a direct intercommunication with enterprise resources.  Decision-making process: As per a Gartner report, organizations lose a cumulative amount of 3% of their profits due to slow or delayed decision-making. Welcome to the new realm of enterprises, where real-time artificially intelligent decision-making is the norm, freeing humans from mundane repetitive tasks and leading to sustainable efficiency.  Implementation/update: These platforms are becoming enormous in size and complexity; its implementation and updates are very time-consuming and involve excessive costs. As final reason, there is an extremely high implementation time.

So, enterprise information systems need more flexibility with explicit and agile workflows to react and quickly adapt to business changes. Then, there is a clear need for more standardization to better support interoperability. The user is still not an IT expert, so zero code is welcomed here. In addition, going to federated interoperability and frequently checking the advances and the support that can be brought by big data and AI is required as well.

We must wonder what we can do now for the information system of the enterprise if it is enhanced by AI. As a dilemma, enterprises want to keep overcoming the ERP platforms, so white box and interoperability are frequently preferred versus AI features for the next generation of ERPs, and it is a current challenge and trade-off to fine-tune the embedding of AI in ERPs [START_REF] Connecza | ERP solution for Educational Organizations|Institutional ERP System[END_REF][START_REF] Shankararaman | Integration of Social Media Technologies with ERP: A Prototype Implementation[END_REF].

Consequently, today's ERP software domain remains looking for more flexibility and agility, making business workflows more efficient or able to react quickly and properly to business changes [START_REF][END_REF]. In addition, some recent results of the literature review article, e.g., proposed by [START_REF] Fitriyani | Literature Review Determination of Planning and Organization in Educational Institutions: Analysis of Leadership and Organizational Culture 2020[END_REF] confirms that the quality of service still highly affects the information system interest and user satisfaction. In addition, the quality of information also affects the satisfaction of users of the information system. There is therefore a need for a platform based on the EOS, and the aim of this article is to present solutions that can achieve these objectives of flexibility and reactivity in the information systems of companies by providing:



A unified platform;  Democratization of data;  Autonomous decision making;  A bespoke operating system developed with Zero-Code.

To attain this, this paper develops a model-based approach from the conceptual level to the implementation. It will track how concepts are derived in the implementation of EOS components.

EOS Architecture Driven by Interoperability

To keep up-to-date, manufacturing enterprises need to use the latest results from the ICT sector, especially when collaborating with external partners in a supply chain and exchanging products and data. It must adapt quickly and deal with an increasing amount of heterogeneous information exchanged between partners, including machines (physical means), humans, and IT; in other words, it must develop interoperability.

As mentioned in the Introduction, interoperability-the ability of the interaction between enterprise systems-remains a barrier in enterprises that ERP intends to overcome. To consider all the dimensions of interoperability, numerous initiatives have been launched for the last two decades to go beyond its simple technical aspect. In that sense, the framework for enterprise interoperability [START_REF]Information Technology -Open Distributed Processing -Reference Model: Architecture[END_REF] offers a structure guiding the development of concepts, methods, and tools for interoperability. Thus, the framework is composed in three dimensions, such as:



Interoperability concerns as the levels in the enterprise where interoperability must be considered (business, process, service, and data);  Interoperability approaches as the ways to develop interoperability and as defined in the ISO 14258 (integrated, unified, and federated);  Interoperability barriers as the problem that an organization may face (conceptual, technological, and organizational).

As shown in Figure 1, the EOS embraces unified and federated methodologies from the incorporation to the full federation by encouraging 'on-the-fly' interoperations and supporting the correspondence and exchanges among heterogeneous and networked enterprises dependent on shared business references. It likewise endeavors to set up interoperability through the conceptual and organizational barriers in the four different levels of concerns by modifying business rules to control activities and tasks, encouraging the arrangement and real-time communication with enterprise operations, giving an instrument to control the authority of accessing the services, and providing a data distribution service for implementing on-the-fly mapping. Moreover, the interoperability approach is applied through the technological barrier and specifically on the level of data by ensuring database connection and remote access. The execution of EOS has been designed to respect the most recent interoperability approaches [START_REF] Chen | Towards an Enterprise Operating System-Requirements for Standardisation[END_REF] to help the improvement of federated and unified methodologies of enterprise interoperability. This respect of interoperability is set from conceptual level down to technical level, where as one of the first implementations, the High-Level Architecture (HLA) [START_REF] Fujimoto | The High Level Architecture: Introduction[END_REF] has been utilized to quickly create an HLA-based interface for achieving federated enterprise interoperability [START_REF] Salinesi | Advanced Information Systems Engineering[END_REF].

Further, interoperability is becoming increasingly critical, but paradoxically, it is not yet fully anticipated, monitored, and accompanied in an effective way to recover from incompatibility problems or failures. [START_REF] Zacharewicz | SLMToolBox: Enterprise service process modelling and simulation by coupling DEVS and services workflow[END_REF] stated that enterprise modeling, enterprise interoperability, and model-driven approaches can contribute, along with systems engineering architecture to develop and improve interoperability in enterprise systems. The Model-Driven Systems Engineering Architecture (MDSEA), extended to interoperability problems, led to the design of the Model-Driven Interoperability System Engineering (MDISE) framework, which leverages enterprise interoperability research and can be used in the transition from EOS concepts to GreneOS operationalization.

EOS to GreneOS

To show the position of the EOS regarding enterprise architecture layers, this section aligns it with the ArchiMate Core framework. The ArchiMate framework is a reference structure used to classify elements and allowing to follow the modeling of the enterprise from different viewpoints, where the position within the cells highlights the concerns of the stakeholder. It consists of three layers (Business, Application, and Technology) and three aspects (Active, Behavior, and Passive). Each cell of the framework makes available a set of modeling objects allowing to describe a specific aspect of an enterprise architecture. The work proposed in this article is situated above the three aspects and three layers, as shown in Figure 2. The ArchiMate Core Framework is guiding and paving the way according to the MDSEA-model-driven approach developed in this project. The following figure shows the positioning of the EOS and GreneOS regarding to the ArchiMate layers.

EOS Meta Model to Conceptual Architectures

This work is based primarily on the EOS metamodel, which presents the basic objects that inspired the development of the EOS architecture and GreneOS. The EOS metamodel highlights the concepts and relationships that need to be instantiated to develop a model at the business level of the enterprise architecture, then derives this model at the application level, then at the technical level, and finally at the solution implementation. As described in Figure 3, it contains the following concepts: Enterprise Resource Management (ERM), Enterprise Process Management (EPM), Enterprise Information Management (EIM), Presentation Management (PM), and Interoperability Management (IM).

Conceptual Architecture

In previous works, the EOS conceptual architecture has been utilized as a frameworkwide stage that enables the business managers to interface with and convey through the enterprise systems (hardware, software, network, machines, human operators...) in a powerful and proficient way [START_REF] Youssef | Developing and Enterprise Operating System (EOS) with the Federated Interoperability Approach[END_REF][START_REF] Ceiton | Front-end and back-end EAI[END_REF].

As shown in the Figure 4, three types of resources have been considered as the components of the Internet-of-Everything, the business managers, and the Interoperability Interface are outside the EOS. They are associated with the EOS to send and get directions (or requests) and data (for example information, inputs, statuses...). To perform endeavor activities (i.e., to design, manufacture and sell required products to customers) in an interoperable and composed way, the assets must be commanded and controlled by business supervisors by means of the EOS. According to Figure 4, the EOS business architecture is made of five services to guarantee the working of the EOS:



Enterprise resource management dynamically monitors the status of enterprise resources, allocates suitable resources to executing operations, and guarantees that the right resources are assigned to the perfect place at the ideal time. It tackles the vision that consists of having a smooth integration of the physical (human, machine), so CPS with the information system is orchestrated by the EOS.



Enterprise process management executes business forms characterized by business clients, sends directions setting off the beginning of procedures, records finishing status of activities (done, fail, not done...), and executes the EOS inner procedures/activities.



Enterprise information management oversees, secures, and supports data and data exchange of different sorts between the enterprise's resources associated with the EOS, and guarantees data and information classification and security to shield from nonapproved access.  Presentation management is a set of services with fitting interfaces that permit business clients and other enterprise resources to associate with the EOS and get/send data.



Interoperability management is a set of services that provides basic mapping between heterogeneous assets to make them interoperable through the EOS [START_REF] Youssef | Enterprise Operating Systems[END_REF].

EOS Implementation Architecture

Implementation architecture describes how to physically realize a framework. It points out and characterizes the technical innovations and concepts chosen to execute the technical architecture. In other words, the implementation architecture identifies the needed technological components and their interactions to build a system.

Initially, the High-Level Architecture (HLA) [START_REF] Fujimoto | The High Level Architecture: Introduction[END_REF] has been utilized to quickly create an HLA-based interface for achieving federated enterprise interoperability [START_REF] Salinesi | Advanced Information Systems Engineering[END_REF].

Broadly speaking, for a given technical architecture, different diverse advancements can be utilized for the execution. In the proposition of [START_REF] Youssef | Enterprise Operating System (EOS) in action: Distributed Simulation of Enterprise Activities and Operations[END_REF], the implementation of the HLA with a Run-Time Infrastructure and federates was chosen [START_REF][END_REF][START_REF] Portico | Portico Space[END_REF]. The fundamental explanations behind this decision were (1) its capability to effortlessly empower federated interoperability between heterogeneous applications and (2) its ability to manage expansive distributed (simulation) environments. Plus, the HLA is likewise in accordance with service orientation-based implementation that is one of the primary attributes of EOS standards. Indeed, an EOS is mostly an IT framework made of numerous services. The HLA gives one conceivable implementation support particularly convenient to the EOS. Nevertheless, the implementation of the EOS is not restricted to the HLA [START_REF] Weichhart | Challenges and current developments for sensing, smart and sustainable enterprise systems[END_REF].

All the EOS federates (EOS components) were associated together through an HLA Federation as to publish and subscribe events between federates. This kind of structure was utilized to facilitate interfederate communications and to help productive data exchange between EOS components when participating in a distributed federation execution [START_REF] Tu | Federated Approach for Enterprise Interoperability: A Reversible Model Driven and HLA Based Methodology[END_REF].

The HLA technology permits the EOS federates to convey information and to synchronize activities among each other, dependent on the federated interoperability features, by characterizing how federates can associate with the RTI, create, join, and manage federations, save, and re-establish federation states and characterize a framework to synchronize federates to a similar time [START_REF] Pokorny | [END_REF].

GreneOS Vision

GreneOS Application Architecture

GreneOS follows the EOS philosophy by eliminating the need to use multiple applications for teams of users and processes replacing most of this disparate applications/software with one unified platform. GreneOS can be considered as one of the most recent implementations of the EOS metamodel. GreneOS connects all employees, customers, vendors, drones, machinery, robots, facilities, and third-party resources to one single platform, making sure that 100% of an enterprise's internal and external resources converse on a single unified platform. This results in a manifold increase in efficiency, transparency, and actionable business intelligence in real-time, launching an end-to-end transformation where GreneOS itself becomes the enterprise's value chain driver.

Figure 5 presents the poles that build GreneOS at the application level. The viewpoint of GreneOS is that decisions are as good as your data. As described in Figure 5, GreneOS intends to bring 100% of the enterprise workforce (human and robotic) onto the platform from the delivery executive to the CEO, with no limit on the number of users and a transaction-based pricing model. GreneOS is an intelligent AI-powered platform that continuously learns and becomes smarter each day with machine learning, in turn making your enterprise hyperefficient and more productive (expect 10 times of × increase in efficiency).

As recommended by the EOS, GreneOS is not a one-size-fits-all application. It is customized and clinically put together for each customer to seamlessly fit into their culture, needs, and challenges. We do not believe in cookie-cutter solutions. Unlike traditional enterprise software, GreneOS can be rapidly deployed within 6-8 weeks thanks to our transformational zero-code development environment that uses a drag-and-drop interface. Once the system is implemented, AI enables it to continuously learn and evolve with every data input and customer feedback, while increasing efficiency and cutting downtime taken to make decisions.

EOS Business to GreneOS Application Architecture

The EOS provides a general framework, meaning that all the features do not need to be systematically implemented in the concrete system that is derived from it. Nevertheless, GreneOS gives a good covering of the EOS functions, as described in Figure 6, even if both approaches derive from the same metamodel. Figure 6 illustrates the transposition from the EOS to GreneOS architectures based on the functionalities, features, and services of each component:



Business Managers and Admins of both the EOS and GreneOS are not monitored and controlled by the platforms; they are the decision-makers who define what and how enterprise operations will be done, manage the activities, and send commands to enterprise resources via the EOS and GreneOS.

 Human, machine, and IT resources connected to the EOS are defined as Employees and Assets for the GreneOS; they are defined as the sets of individuals, machines, and computer elements that are interacting with the EOS and GreneOS.  Both ERM component of the EOS and the Workforce/Workflow Management component of GreneOS provide a real-time and global view of the 'occupation' of the resources in a company by monitoring the enterprise resources system-wide (available, occupied, out-of-order…).



The EPM component of the EOS, same as the Activity/Bot/Analytics Engines of Gre-neOS, are responsible for interpreting process behavioral, information, and resource requirements.



The Presentation Management module set services are the same for both approaches; this component with the appropriate interfaces allows business users and other enterprise resources to connect to the EOS and GreneOS and receive/send information.



The Interoperability Management component of the EOS plays the same role as the Integration/Migration Engines of the GreneOS; they are presented as sets of features that provide necessary mapping between heterogeneous resources to make them interoperable through the EOS and GreneOS. Figure 7 illustrates and presents an EOS application layer as workflow where the enterprise operations are executed and generated through the EOS internal components [START_REF] Youssef | Developing and Enterprise Operating System (EOS)-State of the Art[END_REF], noting that this architecture is designed using the HLA technology during the year 2017. The final objective is executing this workflow within the GreneOS technical architecture. At first, each decision-maker accesses the General-Purpose and Vertical software interfaces to request a new job from the day-to-day list of activities and operations. The software sends related commands and data to communicate with the EOS front-end interface named Presentation Module to execute the requested job.

The Presentation Module then interprets the run-time entities, creates the events which will be registered with their associated information by the Event Registration Component using the Run-Time Repository Service, and produces event occurrences for the Event Handling component.

Next, the Event Handling deals with the event occurrence needs, lines, and traceability, and gives the request identifier and makes the Process Occurrence. The Process Occurrence requests planning from the Process Scheduling part, which deciphers the process behavior, data, and resource necessities. This subservice checks the approval to execute the process, recovers process depictions from the Run-Time Repository, summons the Enterprise Resource Management to allocate the needed resource capabilities, and advances the details to the Rule Interpretation segment.

Afterward, the Rule Interpretation segment provides usefulness to recover the sequencing and contingent principles related with the distinguished Enterprise Process, saves a state record of all enterprise activities, and reacts to identified events to instate or end the activity.

In this manner, the Activity Occurrence plan made by the Rule Interpretation is sent to the Interoperability Component, which is trustworthy and asks the Enterprise Resource Management to appoint assets apportioned by the Process Scheduling Component, conjuring the Enterprise Information Management to acquire the item states and demonstrate the information object required, asking the Enterprise Resource Management to: assign resources designated by the Process Scheduling segment, discharge the involved resources, while ending an activity and notifying the termination of the present action to the Rule Interpretation component [START_REF] Chen | Towards an Enterprise Operating System-Requirements for Standardisation[END_REF].

The Resource Controlling part checks the accessibility of the resources and preallots them when accessible, reacts to the Interoperability Controlling solicitations to relegate specialists, and reacts to the Process Scheduling requests to designate and deallocate resources.

The Resource Handling segment guarantees asset streamlining and resource mapping by choosing the proper resources after coordinating the abilities required and by thinking about the time, performance, and priority.

The Presentation Management services are constrained by the Resource Handling Component for dealing with Human, Machine, and IT Dialogs:



The Human Dialog provides usefulness by introducing in the fitting configuration the present status and the previous history of occasions, enabling authorized persons to mediate manually to adjust the relevant parameters at run-time.



The Machine Dialog bolsters the vital features to give access to the different functional capabilities of the machine. It provides the usefulness required to receive and decipher responses from the machine.



The IT Dialog gives functionality to the cross-examining application program interfaces to decide its capacities, offering help for the joining of the practical substances executed by existing IT application programs.

GreneOS Technical Architecture

One of the core aspects of GreneOS is the unification of all resources in an enterprise. The resources here could include humans and any other IoT based devices that are part of the enterprise. Hence, it was established that we will have to deal with huge volumes of data when data are being captured from the entire spectrum of resources.

To handle such huge volumes of data, we have gone ahead with a decoupled data stream architecture described in Figure 8. As you can see in this diagram, the data requests are not immediately processed. First, the data are produced on to the messaging system and immediately an acknowledgement is sent to the client applications stating that the request has been received. On the other side of messaging systems, we have consumer engines that process the request data asynchronously. This enables the system to handle higher loads with the same amount of computation power, as the connections with the clients are not persisted until the processing of the data is completed. Another important aspect of this architecture is that all the server-side components are loosely coupled to the data stream. Especially, every storage application is abstracted by the presence of a wrapper code. This essentially builds a lot of futureproofing into the architecture, as it will be easy to replace a specific server component when there are more competent technologies available. Now, let us look at the typical data flow. Client apps send requests, which are received by controllers on the server side. Upon receiving requests, the controllers convert the request to a standard message format while incorporating the required metadata to identify the endpoint of the request. Converted messages are then produced to the messaging system. Consumers retrieve the produced messages on the other side of the messaging system. The consumer identifies the corresponding service component by retrieving the endpoint from the metadata. The consumer then invokes the corresponding service for the message. The service processes the data based on the specific use case copies and transforms data into one or multiple storage applications. Please note that only write requests leverage the decoupled data stream architecture. For all the read requests, the messaging system is bypassed and the service is directly invoked.

Use Case

EOS Workflow to Orchestrate GreneOS Technical Architectures

The matching between both technical architectures (GreneOS and EOS) is based on the functionalities, features, and services of each component.

The General-Purpose Vertical Software of the EOS and the core applications (Media, iOS, Android, Web) of GreneOS play the same role as computing resources that request a new job from the day-to-day list of activities and operations. The software sends related commands and data to communicate with the EOS or GreneOS

The ERM module of the EOS containing the Resource Handling and Resource Controlling components is matched with the Ordered Messaging System of GreneOS; they have the role to check the availability of the resources and preassign them when available, assign agents, and ensure the resource optimization and the resource mapping by selecting the appropriate resources after matching the capabilities required and by taking into consideration the time, performance, and priority Both the EIM component (Information Library and Object) of the EOS and the Persistent/Analytics/Time/Search Databases of GreneOS must manage the exchanged messages and information between resources, acquire the object states, and specify the information object required

The IM component of the EOS plays the same role as the Consumer Group of Gre-neOS: it requests from the Resource Management to assign the specified resources/employees/assets and invokes the EIM/Databases to acquire the information and data.

Use-case EOS Workflow with GreneOS GreneOS can handle a workflow process initiated from a discussion with a chatbot presenting different journey options of resources users. The use-case example is described in Figure 9. The implementation of "Business Manager requires a new job" is being detailed with the interfaces of GreneOS. Figure 9 presents how the user chat interface on the smartphone with the workflow part.

It starts from the client apps that send requests which are received by controllers on the server-side. Upon receiving requests, the controllers convert the request to a standard message format while incorporating the required metadata to identify the endpoint of the request. Then, the converted messages are produced to the messaging system. At that point, according to Figure 8 descriptions, consumers retrieve the produced messages on the other side of the messaging system. At that time, the consumer identifies the corresponding service component by retrieving the endpoint from the metadata. The consumer then invokes the corresponding service for the message. From the service component, the following modules will be invoked based on the use case-Bot Engine, Analytics Engine, and Integration Engine. The Bot Engine drives all the autonomy that is relevant for the current data request type. Likewise, Analytics Engine is fired to crunch the data required to drive the dashboards and reports, and the Integration engine is fired to exchange data with the partner systems. Finally, postprocessing of the data based on the specific use-case copies will have transformed the data into one or multiple storage applications.

Discussion and Perspective

Workflow from WFMC

Founded in 1993, the Workflow Management Coalition (WfMC) is a global organization based on diverse groups of workflow and BPM contributors. Based on WfMC works, [START_REF] Zacharewicz | HLA Supported Federation Oriented Enterprise Interoperability, Application to Aerospace Enterprises[END_REF] previously announced that there is a crucial need for a workflow-explicit orchestration editor revealing and proposing to edit the most frequently hidden processes of the information. Yet, few ERPs are including an explicit workflow editor, making the user tempted to adapt his process more easily to the one defined in the ERP while it should be the ERP that should adapt. The EOS has a role to play in the proposition of workflow editors and transformation into executable processes.

From another perspective, process discovery (including process mining [START_REF] Van Der Aalst | Process mining: Overview and opportunities[END_REF] with the reuse of legacy processes and the mapping of existing processes may be of interest to enhance the EOS with an artificial intelligence function to define processes in an automated or guided manner. One can imagine an adaptive workflow progressively built from the chat option chosen in the discussion.

ESB and SOA

The Enterprise Service Bus (ESB) has been defined since [START_REF] Guerola-Navarro | Customer relationship management and its impact on innovation: A Lit[END_REF][START_REF] Schmidt | The enterprise service bus: making service-oriented architecture real[END_REF] as a set of tools that guarantee the confidence of data exchanges between the sources and targets of an information system. Thus, it is implemented to allow heterogeneous applications to connect (connectivity) and share/exchange information (interoperability) through a software architecture. Recent works [START_REF] Shkuta | Comparative analysis of tools for the integration of IT systems[END_REF] show that the ESB methods, approaches, and technologies have now reached a good maturity of functionality in combination with selected tools to achieve a good integration of information systems. A recent systematic literature study [START_REF] Aziz | Research Trends in Enterprise Service Bus (ESB) Applications: A Systematic Mapping Study[END_REF] explained that ESB remains the best promising way for the integration of business applications in distributed and diverse environments. Nevertheless, ESB works by a data exchange structure that is mostly standardized and, rather than making direct interfaces between applications, these applications subscribe to the messages available in the ESB that interest them [START_REF] Turner | Advances in Home Care Technologies, Results of the MATCH Project[END_REF].

In the frame of the EOS, the main component of an ESB is still a route that allows information to circulate between applications (an "application bus") and whose purpose is to guarantee the routing of data as well as its persistence [START_REF] Zurawski | The Industrial Information Technology Handbook[END_REF]. However, in addition, we assume that the bus connection can be achieved with connectors (interoperability with legacy [START_REF] Chen | Framework for enterprise interoperability[END_REF] implemented with low code obtained again from discussion with users. So, the EOS supports data transport in a more flexible way, being supported by ontologies and semantics with the ability to route and deliver large volumes of data in real time more easily.

The ESB is a part of SOA for business integration, which is an avenue of research. The research proposed by [START_REF] Grant | Enterprise integration using Service-Oriented Architecture[END_REF] addresses this integration by proposing a conceptual SOA model for achieving different levels of enterprise integration.

Graphical Editor and Visualization Tools

The workflow can be built on the fly upon the discussion between the chatbots and users thanks to modeling and simulation tools. We can assume that model animation can guide the user in the setting of the workflow before to launch it. The heat map is now frequently used in the domain of process modeling and can be transposed to the EOS.

Conclusions

This article started from the observation that current ERP systems are still limited by customization, implementation time, and interoperability with other systems.

A first contribution of the article is the detailed explanation, using the ArchiMate formalism, of the conceptual architecture, the technical architecture, and the implementation architecture of the EOS following the previous conceptual contributions about the EOS. The paper also shows how the EOS is guided by interoperability in the MDSEA framework. Therefore, it demonstrates that the EOS can be used to address the services and functionalities needed for Enterprise 4.0.

To go further, this conceptual architecture with the basic functions proposed in the EOS, as well as the technical architecture were applied to GreneOS, which is one of the first operational implementation architectures benefiting from the innovation and concept of the EOS. This demonstrated a successful implementation in a robust technical architecture driven by the EOS concepts.

The article therefore discusses the current interest of EOS with an application case, showing the complementarity and the limits of the conceptual architecture of the EOS and its implementation in GreneOS. It finally concludes by proposing perspectives for future developments of the EOS.

Figure 1 .

 1 Figure 1. EOS positioned in the interoperability framework.

Figure 2 .

 2 Figure 2. EOS within the ArchiMate Core framework.

Figure 3 .

 3 Figure 3. EOS metamodel.

Figure 4 .

 4 Figure 4. EOS business architecture.

Figure 5 .

 5 Figure 5. GreneOS application architecture.

Figure 6 .

 6 Figure 6. Alignment of EOS business architecture with GreneOS application architecture.

Figure 7 .

 7 Figure 7. EOS workflow at application layer.

Figure 8 .

 8 Figure 8. GreneOS Technical Architecture.

Figure 9 .

 9 Figure 9. GreneOS tasks management in a chat.

Funding: This research received no external funding.

Institutional Review Board Statement: Not applicable.

Informed Consent Statement: Not applicable.

Data Availability Statement: All data has been presented in main text.

Conflicts of Interest:

The authors declare no conflict of interest.