<figure><img src="image_7.png" /><figcaption>Figure 1: Definition of ACTRIS data levels applicable to all variables. ACTRIS digital tools can apply to all levels.</figcaption></figure>

## 2.2 Scientific relevance, main tasks and structure of the data centre

The role and tasks of the ACTRIS Data Centre are multi-fold as the DC will offer a wide suite of services related to ACTRIS data, data products, and digital tools. These must include:

* Long-term archiving and preservation of ACTRIS level 1 to level 3 data and data products,

* Access to ACTRIS data, data products, and digital tools through a single point of entry, the ACTRIS data user interface

* Documentation of data, data flow, citation service, and data attribution, including version control, data traceability, and interoperability,

* Data curation and support for campaigns and dedicated research projects and initiatives, external or internal to ACTRIS.

To meet the needs of NFs, TCs and users of ACTRIS data, ACTRIS DC will offer 5 mandatory core data services:

### I. Data Curation

ACTRIS DC must offer repositories and long term archive and preservation of ACTRIS data and data products.

### II. Access to level 0 – level 3 data

ACTRIS DC must offer access to data, data products and digital tools through a single entry point, the ACTRIS Data Centre web interface.
### III. Documentation

ACTRIS DC must offer documentation of data through meta data, data flow, citation service (Digital object identifier) and data attribution.

### IV. Data products and digital tools

ACTRIS DC must produce advanced data products and implement data production tools for advanced data products.

### V. User community support and services

ACTRIS DC must offer training, help desk, tutorials, for data producers and users, including support to regional and global networks

The numerous measurement methodologies applied within ACTRIS (described in "*Technical concepts and requirements for ACTRIS Observational Platforms*"<fnref n="2" />), and listed in Annex I, result in a considerable diversity of data collected; ACTRIS provides advanced data and data products requiring a complex and well described data curation system. In accordance with these requirements, the ACTRIS Data Centre is foreseen to consist of a set of data centre units, each meeting the specific requirements and needs for the diversity of the remote and in situ data, about 50 atmospheric variables, where the trace gases are grouped. Counting all different traces gases, the numbers of variables and components is more than 150 in total, excluding auxiliary data. Annex I includes the ACTRIS variables from observational platforms associated with the measurement methodologies within ACTRIS. Additionally, ACTRIS level 3 products are offered, listed in Annex II.

For an ACTRIS DC consisting of a set of units, each ACTRIS topical DC unit must be responsible for the data curation of their specific subset of data, and linked to the corresponding topic centre (TC) with clearly defined roles to facilitate efficient work flow, and to ensure adequate and complementary competence and required quality at all levels of the data flow. Independent of any DC units, all ACTRIS level 1-2-3 data are required to be available and accessible through a single entry point, the ACTRIS Data Centre web interface. Figure 2 is a schematic diagram displaying the potential architecture of the ACTRIS Data Centre, with the requisite links and interactions with TCs and NFs. The structure and architecture proposed is based on more than 15 years of experience with curation of ACTRIS datatypes through a list of EU projects (ACTRIS-2, ACTRIS-FP7, EUSAAR, CREATE, EARLINET, EARLINET-ASOS, CLOUDNET, EUROCHAMP, etc.) and also within EMEP, GAW-WDCA, GAW-WDCRG.

<footnote n="2">² Refer to Deliverable D5.1: *Documentation on technical concepts and requirements for ACTRIS Observational Platforms*.</footnote>
### III. Documentation

ACTRIS DC must offer documentation of data through meta data, data flow, citation service (Digital object identifier) and data attribution.

### IV. Data products and digital tools

ACTRIS DC must produce advanced data products and implement data production tools for advanced data products.

### V. User community support and services

ACTRIS DC must offer training, help desk, tutorials, for data producers and users, including support to regional and global networks

The numerous measurement methodologies applied within ACTRIS (described in "*Technical concepts and requirements for ACTRIS Observational Platforms*"<fnref n="2" />), and listed in Annex I, result in a considerable diversity of data collected; ACTRIS provides advanced data and data products requiring a complex and well described data curation system. In accordance with these requirements, the ACTRIS Data Centre is foreseen to consist of a set of data centre units, each meeting the specific requirements and needs for the diversity of the remote and in situ data, about 50 atmospheric variables, where the trace gases are grouped. Counting all different traces gases, the numbers of variables and components is more than 150 in total, excluding auxiliary data. Annex I includes the ACTRIS variables from observational platforms associated with the measurement methodologies within ACTRIS. Additionally, ACTRIS level 3 products are offered, listed in Annex II.

For an ACTRIS DC consisting of a set of units, each ACTRIS topical DC unit must be responsible for the data curation of their specific subset of data, and linked to the corresponding topic centre (TC) with clearly defined roles to facilitate efficient work flow, and to ensure adequate and complementary competence and required quality at all levels of the data flow. Independent of any DC units, all ACTRIS level 1-2-3 data are required to be available and accessible through a single entry point, the ACTRIS Data Centre web interface. Figure 2 is a schematic diagram displaying the potential architecture of the ACTRIS Data Centre, with the requisite links and interactions with TCs and NFs. The structure and architecture proposed is based on more than 15 years of experience with curation of ACTRIS datatypes through a list of EU projects (ACTRIS-2, ACTRIS-FP7, EUSAAR, CREATE, EARLINET, EARLINET-ASOS, CLOUDNET, EUROCHAMP, etc.) and also within EMEP, GAW-WDCA, GAW-WDCRG.

<footnote n="2">² Refer to Deliverable D5.1: *Documentation on technical concepts and requirements for ACTRIS Observational Platforms*.</footnote>
<figure><img src="image_7.png" /></figure>

Figure 2: Schematic diagram of a potential architecture of the ACTRIS Data Centre, with examples of proper interactions between the TC and NF. The blue circles illustrate the NFs of various extent. There may be multiple access interface and levels depending on the need.

As indicated in Figure 2, the blue circles are symbols for NFs. Depending on the observational components included at the NF (see the general Principle #1 in "D5.1: Documentation on technical concepts and requirements for ACTRIS Observational Platforms") NFs must interact with the various components of- the DC, and submit data, and also interact with various required TCs, before data submission.

In case of distributed data nodes, each topical DC node requires an interface to the overarching ACTRIS Data Centre user interface, where all Level 2 and level 3 data will be identifiable and accessible, together with level 1 data (e.g. RRT data) when these are available, and relevant. This requires that data are documented by a comprehensive metadata throughout the whole data curation chain, where the metadata suite conforms to standards (e.g. ISO19115 and INSPIRE). The documentation includes references to standardized operation procedures, this requires close interactions and clearly defined workflows and procedures with the TCs.
<figure><img src="image_8.png" /></figure>

Figure 2: Schematic diagram of a potential architecture of the ACTRIS Data Centre, with examples of proper interactions between the TC and NF. The blue circles illustrate the NFs of various extent. There may be multiple access interface and levels depending on the need.

As indicated in Figure 2, the blue circles are symbols for NFs. Depending on the observational components included at the NF (see the general Principle #1 in "D5.1: Documentation on technical concepts and requirements for ACTRIS Observational Platforms") NFs must interact with the various components of- the DC, and submit data, and also interact with various required TCs, before data submission.

In case of distributed data nodes, each topical DC node requires an interface to the overarching ACTRIS Data Centre user interface, where all Level 2 and level 3 data will be identifiable and accessible, together with level 1 data (e.g. RRT data) when these are available, and relevant. This requires that data are documented by a comprehensive metadata throughout the whole data curation chain, where the metadata suite conforms to standards (e.g. ISO19115 and INSPIRE). The documentation includes references to standardized operation procedures, this requires close interactions and clearly defined workflows and procedures with the TCs.
## 2.3 ACTRIS Data Centre mission

The mission of the ACTRIS Data Centre is to compile, archive and provide access to well documented and traceable ACTRIS measurement data and data products, including digital tools for visualisation, data analysis and research. As a tool for science, the highest priorities for the ACTRIS DC are to maintain and increase the availability of ACTRIS data and data products relevant to climate and air quality research for all interested users. National and international climate and air quality assessments for National and International Environmental agencies are also based on ACTRIS data and are the ultimate user of ACTRIS data and data products. Additionally, the data centre shall provide training and customized services including tools, tutorials, documentation for the NFs and ACTRIS data originators.

# 3 Data service support provided to ACTRIS National Facilities

The ACTRIS Data Centre is required to provide operation support to NFs in form of procedures, tools and data production, data quality assurance, data quality control, and data curation. The operation support related to data production and quality control follows predefined and standardized procedures and tools developed by ACTRIS DC in close collaboration with TCs. ACTRIS DC will offer training for each NF related to tasks such as data production, quality control tools meta data requirements, data submissions and data flow.

The operation support offered to NFs shall include the data resulting from measurement techniques described in technical centre concept documents, also listed in Annex I for the various variables.

ACTRIS DC is obliged to put in place and offer to NFs the specific operation support marked with * in this document. Other operation support described in this document is not mandatory for the data centre, but is recommended or can be associated to access managed by SAMU and potentially a fee.

The operation support may be scheduled or on request. Participation in scheduled activities is mandatory for NFs. Measurements not following the mandatory actions are not considered as ACTRIS-conformant and do not yield ACTRIS data.

## 3.1 Required data curation services provided by the ACTRIS Data Centre

The ACTRIS DC is responsible for data curation of all ACTRIS variables; if the ACTRIS DC is distributed across a number of nodes, then each DC node is responsible for the curation of the associated subset of well-defined variables, so that the DC as a whole covers all ACTRIS variables. All data centre units responsible for data curation of ACTRIS data have to offer the following service for data curation of data from NF, both observational and exploratory platforms:

* Long-term sustainable archive for ACTRIS level 2 data provided by NFs with regular, frequent back up, at least weekly, ideally every night, dependent on data type, and described in the following sections,

* Organise and set up procedures for long-term archive of ACTRIS level 0 and selected level 1 data from the NFs with regular, back up
## 2.3 ACTRIS Data Centre mission

The mission of the ACTRIS Data Centre is to compile, archive and provide access to well documented and traceable ACTRIS measurement data and data products, including digital tools for visualisation, data analysis and research. As a tool for science, the highest priorities for the ACTRIS DC are to maintain and increase the availability of ACTRIS data and data products relevant to climate and air quality research for all interested users. National and international climate and air quality assessments for National and International Environmental agencies are also based on ACTRIS data and are the ultimate user of ACTRIS data and data products. Additionally, the data centre shall provide training and customized services including tools, tutorials, documentation for the NFs and ACTRIS data originators.

# 3 Data service support provided to ACTRIS National Facilities

The ACTRIS Data Centre is required to provide operation support to NFs in form of procedures, tools and data production, data quality assurance, data quality control, and data curation. The operation support related to data production and quality control follows predefined and standardized procedures and tools developed by ACTRIS DC in close collaboration with TCs. ACTRIS DC will offer training for each NF related to tasks such as data production, quality control tools meta data requirements, data submissions and data flow.

The operation support offered to NFs shall include the data resulting from measurement techniques described in technical centre concept documents, also listed in Annex I for the various variables.

ACTRIS DC is obliged to put in place and offer to NFs the specific operation support marked with * in this document. Other operation support described in this document is not mandatory for the data centre, but is recommended or can be associated to access managed by SAMU and potentially a fee.

The operation support may be scheduled or on request. Participation in scheduled activities is mandatory for NFs. Measurements not following the mandatory actions are not considered as ACTRIS-conformant and do not yield ACTRIS data.

## 3.1 Required data curation services provided by the ACTRIS Data Centre

The ACTRIS DC is responsible for data curation of all ACTRIS variables; if the ACTRIS DC is distributed across a number of nodes, then each DC node is responsible for the curation of the associated subset of well-defined variables, so that the DC as a whole covers all ACTRIS variables. All data centre units responsible for data curation of ACTRIS data have to offer the following service for data curation of data from NF, both observational and exploratory platforms:

* Long-term sustainable archive for ACTRIS level 2 data provided by NFs with regular, frequent back up, at least weekly, ideally every night, dependent on data type, and described in the following sections,

* Organise and set up procedures for long-term archive of ACTRIS level 0 and selected level 1 data from the NFs with regular, back up
* Back up of level 2 and level 3 data and data products to a different location,

* Development and implementation of data production tools (software and digital tools) for generating the required data levels,

* Implementation of data quality control tools and procedures developed in DC or TCs,

* Portal for standardised submission of data by NF operators to DC,

* Standardised sanity and consistency checks of data submitted through submission service,

* Development and maintenance of tools for quality control of data, including implementation of new quality assurance criteria defined by TCs,

* Tools for performing quality controls homogeneously at NF,

* Implementation of data flow for new instruments from NF to DC in collaboration with TCs.

* Automatic and centralized processing tools for achieving quality assured and real time (RRT) data from observational NF platforms at network level.

* Data curation of data from the topical centres for internal use for documenting provenance and QA/QC, and for external users as reference data

### 3.1.1 Data curation service and tools for ACTRIS in situ aerosol, cloud, and trace gas data

All ACTRIS in situ<fnref n="3" /> aerosol, cloud, and trace gas variables are listed in Annex 1, associated with their instrument type and potential for real-real-time (RRT) data. Measurements of atmospheric aerosol-, cloud and gas variables at ACTRIS NFs that represent the in situ conditions need to be organised in 2 groups: *online and offline observations*

* **Online observations:** Air stream enters the station or instrument enclosure through an inlet, and is led to the instrument itself. The measurement is conducted and reported by the instrument as the sample passes through the instrument. Instrument-side quality assurance measures consist of on- or off-site comparisons to standard instruments or primary standards. RRT data provision is possible

* **Offline observations:** Air stream enters the station or enclosure through an inlet, and is conducted to a sample medium. The sample medium either stores the whole sample, or extracts a part of the sample and stores it. The sample medium is transported to an analysis facility, where it also has been pre-treated before exposure. At the analysis facility, the sample undergoes the steps of preparation and analysis to yield actual variable. Quality assurance concerns the field side (field blanks) as well as the analysis side of the process (round-robin analysis). RRT data provision is not possible.

There might be combinations of these, where the offline analysis process has been streamlined enough to fit an online time schedule.

<footnote n="3">³ See Glossary</footnote>
* Back up of level 2 and level 3 data and data products to a different location,

* Development and implementation of data production tools (software and digital tools) for generating the required data levels,

* Implementation of data quality control tools and procedures developed in DC or TCs,

* Portal for standardised submission of data by NF operators to DC,

* Standardised sanity and consistency checks of data submitted through submission service,

* Development and maintenance of tools for quality control of data, including implementation of new quality assurance criteria defined by TCs,

* Tools for performing quality controls homogeneously at NF,

* Implementation of data flow for new instruments from NF to DC in collaboration with TCs.

* Automatic and centralized processing tools for achieving quality assured and real time (RRT) data from observational NF platforms at network level.

* Data curation of data from the topical centres for internal use for documenting provenance and QA/QC, and for external users as reference data

### 3.1.1 Data curation service and tools for ACTRIS in situ aerosol, cloud, and trace gas data

All ACTRIS in situ<fnref n="3" /> aerosol, cloud, and trace gas variables are listed in Annex 1, associated with their instrument type and potential for real-real-time (RRT) data. Measurements of atmospheric aerosol-, cloud and gas variables at ACTRIS NFs that represent the in situ conditions need to be organised in 2 groups: *online and offline observations*

* **Online observations:** Air stream enters the station or instrument enclosure through an inlet, and is led to the instrument itself. The measurement is conducted and reported by the instrument as the sample passes through the instrument. Instrument-side quality assurance measures consist of on- or off-site comparisons to standard instruments or primary standards. RRT data provision is possible

* **Offline observations:** Air stream enters the station or enclosure through an inlet, and is conducted to a sample medium. The sample medium either stores the whole sample, or extracts a part of the sample and stores it. The sample medium is transported to an analysis facility, where it also has been pre-treated before exposure. At the analysis facility, the sample undergoes the steps of preparation and analysis to yield actual variable. Quality assurance concerns the field side (field blanks) as well as the analysis side of the process (round-robin analysis). RRT data provision is not possible.

There might be combinations of these, where the offline analysis process has been streamlined enough to fit an online time schedule.

<footnote n="3">³ See Glossary</footnote>
The ACTRIS data levels are described in Figure 1. A more detailed description of data levels for in situ data is following, in agreement with the general description:

*   **Level 0:** raw data as produced by the instrument, all main and instrument status parameters provided by instrument, brought to a common, well-defined data format. Discovery, use, provenance, and configuration metadata attached, including all information needed for further data production, as far as known at stations level (e.g. QC metadata). Content is instrument model specific, time resolution as native to the instrument, reference conditions of temperature and pressure conditions as provided by instrument.

*   **Level 1:** Produced from level 0 data to contain the physical property to be observed, including measures of uncertainty. Instrument status parameters, QC measurements and invalid data removed, quality control and post-calibrations applied. Time resolution native to instrument. Content specific for measured property, standard conditions of temperature and pressure.

*   **Level 2:** Produced from level 1 data to contain data averaged to a homogeneous time resolution, typically 1 h. Includes measure of atmospheric variability, content specific for measured property.

### 1.1.1.1 Data curation service of online ACTRIS in situ data

Data curation of online ACTRIS in situ data starts with the raw data stream coming from the instrument. Already at the station, the raw data stream is transcribed to a homogeneous level 0 format, and annotated with discovery, use, provenance, and configuration metadata. The level 0 data are uploaded to the ACTRIS DC at a real-real-time (RRT) schedule (latest 3 h after measurement) to facilitate rapid discovery of potential high/low episodes, detections of errors, and to provide RRT data for operational services.

Next in the data production flow, the data receives quality control (QC). Two QC options are foreseen:

1.  **Automatic QC:** inspection of data by an algorithm for outliers, spikes, and automatically identifiable instrument malfunctions. The data are flagged accordingly. Automatic QC is typically applied for RRT data.

2.  **Manual QC:** inspection of data by an identified person under the responsibility of the NF. The QC includes at least tests for outliers (with location-specific threshold values), spikes, episodes (e.g. atmospheric transport, local / regional contamination), instrument malfunctions, and verification of correctly applied instrument QC, e.g. calibrations. The data are flagged accordingly. Manual QC is applied at least at an annual frequency.

As a general rule in ACTRIS in situ data QC, only data subject to instrument malfunctions are flagged as invalid. Data with episodes are flagged as such, but not as invalid, to avoid limiting data use only to certain use cases. From this point in the data curation workflow, data level designations are to distinguish between data having received automatic QC or also undergone manual QC of the data.

The workflow for ACTRIS surface in situ data production offers an option for a review process during data QC. For this purpose, the level 0 data QCed by the NF are made available to a review process in a machine-to-machine interface, where the review process is administered by the responsible TC. The TC organises the review process and defines the review criteria. The DC assists in the process by providing a web-based issue tracker where the review process is traceably documented for each dataset by assigning QC tasks to
The ACTRIS data levels are described in Figure 1. A more detailed description of data levels for in situ data
is following, in agreement with the general description:

*   **Level 0:** raw data as produced by the instrument, all main and instrument status parameters provided by instrument, brought to a common, well-defined data format. Discovery, use, provenance, and configuration metadata attached, including all information needed for further data production, as far as known at stations level (e.g. QC metadata). Content is instrument model specific, time resolution as native to the instrument, reference conditions of temperature and pressure conditions as provided by instrument.

*   **Level 1:** Produced from level 0 data to contain the physical property to be observed, including measures of uncertainty. Instrument status parameters, QC measurements and invalid data removed, quality control and post-calibrations applied. Time resolution native to instrument. Content specific for measured property, standard conditions of temperature and pressure.

*   **Level 2:** Produced from level 1 data to contain data averaged to a homogeneous time resolution, typically 1 h. Includes measure of atmospheric variability, content specific for measured property.

1.1.1.1 Data curation service of online ACTRIS in situ data

Data curation of online ACTRIS in situ data starts with the raw data stream coming from the instrument.
Already at the station, the raw data stream is transcribed to a homogeneous level 0 format, and annotated
with discovery, use, provenance, and configuration metadata. The level 0 data are uploaded to the ACTRIS
DC at a real-real-time (RRT) schedule (latest 3 h after measurement) to facilitate rapid discovery of
potential high/low episodes, detections of errors, and to provide RRT data for operational services.

Next in the data production flow, the data receives quality control (QC). Two QC options are foreseen:

1.  **Automatic QC:** inspection of data by an algorithm for outliers, spikes, and automatically identifiable instrument malfunctions. The data are flagged accordingly. Automatic QC is typically applied for RRT data.

2.  **Manual QC:** inspection of data by an identified person under the responsibility of the NF. The QC includes at least tests for outliers (with location-specific threshold values), spikes, episodes (e.g. atmospheric transport, local / regional contamination), instrument malfunctions, and verification of correctly applied instrument QC, e.g. calibrations. The data are flagged accordingly. Manual QC is applied at least at an annual frequency.

As a general rule in ACTRIS in situ data QC, only data subject to instrument malfunctions are flagged as invalid. Data with episodes are flagged as such, but not as invalid, to avoid limiting data use only to certain use cases. From this point in the data curation workflow, data level designations are to distinguish between data having received automatic QC or also undergone manual QC of the data.

The workflow for ACTRIS surface in situ data production offers an option for a review process during data QC. For this purpose, the level 0 data QCed by the NF are made available to a review process in a machine-to-machine interface, where the review process is administered by the responsible TC. The TC organises the review process and defines the review criteria. The DC assists in the process by providing a web-based issue tracker where the review process is traceably documented for each dataset by assigning QC tasks to
the NF responsible for the dataset. Successful completion of the review process is documented in the QC
metadata.

The QCed level 0 data are the basis for producing level 1 data. This production step includes calculation of the final physical property from raw signals, application of corrections and post-calibrations, measures of uncertainty, removal of periods with invalid or calibration data, and inclusion of metadata on instrument QA measures conducted by the TC, where the QA measure metadata is maintained by the TC.

The production step from data level 1 to data level 2 comprises averaging of the data to a common time resolution, usually hourly, where invalid data is disregarded in the averaging process, and episode flags occurring in the averaging period are copied to the average value. Also included are flags for data coverage during the averaging period, and measures of atmospheric variability during the averaging period.

Finally, level 2 data are inserted into the ACTRIS surface in situ data repository, and public and available to all users. Immediately before, data are subjected to a final QC, covering syntactic and semantic correctness of metadata, syntactic correctness of data, parameter dependent completeness of metadata, and completeness and correctness of framework associations. By inserting the data into the repository, the data are released and published in the release channels of the ACTRIS surface in situ repository (web-interface, data and metadata machine-to-machine interfaces) as well as the ACTRIS data user interface.

1.1.1.2 Data curation service of offline ACTRIS in situ data

For measurements using the offline workflow for ACTRIS surface in situ data, data production starts with the sample medium. At the NF central lab, the sample medium is pre-treated, i.e. prepared for being exposed. Depending on the requirements of the measurement method, pre-treatment may include pre-heating, impregnation, weighing-in, pre-cleaning, or other methods of conditioning. The pre-treatment is documented by a protocol, where the NF is responsible for correct documentation.

Following pre-treatment, the sample medium is exposed to air sample at the NFs field site. The step is documented by a protocol, including e.g. medium ID, exposure begin and end time, sample amount collected, exposure standard protocol ID, and others. The NF is responsible for correctly assembling this documentation.

After exposure and transporting the sample medium back to the NF's central lab, the sample medium is prepared for analysis. This step may comprise weighing-out, medium extraction, partitioning of sample medium, or other steps as required by the method. The corresponding protocol, assembled under the responsibility of the NF, may contain parameters like medium ID, preparation time, preparation protocol, numerical preparation results, or others.

Finally, the sample extracted from the sample medium is analysed at the NF. The pertaining protocol, assembled responsibly by the NF, contains parameters such as sample medium ID, extract ID, analysis, device type and ID, numerical analysis results, and others.

All protocols of sample medium and sample extract treatment generated in the workflow are stored in machine-readable form in a sample and analysis database. Operation of this database is to meet long-term archive standards, e.g. intervals of upgrading database hard- and software, and frequent schedule for on- and off-site backups.
the NF responsible for the dataset. Successful completion of the review process is documented in the QC
metadata.

The QCed level 0 data are the basis for producing level 1 data. This production step includes calculation of the final physical property from raw signals, application of corrections and post-calibrations, measures of uncertainty, removal of periods with invalid or calibration data, and inclusion of metadata on instrument QA measures conducted by the TC, where the QA measure metadata is maintained by the TC.

The production step from data level 1 to data level 2 comprises averaging of the data to a common time resolution, usually hourly, where invalid data is disregarded in the averaging process, and episode flags occurring in the averaging period are copied to the average value. Also included are flags for data coverage during the averaging period, and measures of atmospheric variability during the averaging period.

Finally, level 2 data are inserted into the ACTRIS surface in situ data repository, and public and available to all users. Immediately before, data are subjected to a final QC, covering syntactic and semantic correctness of metadata, syntactic correctness of data, parameter dependent completeness of metadata, and completeness and correctness of framework associations. By inserting the data into the repository, the data are released and published in the release channels of the ACTRIS surface in situ repository (web-interface, data and metadata machine-to-machine interfaces) as well as the ACTRIS data user interface.

1.1.1.2 Data curation service of offline ACTRIS in situ data

For measurements using the offline workflow for ACTRIS surface in situ data, data production starts with the sample medium. At the NF central lab, the sample medium is pre-treated, i.e. prepared for being exposed. Depending on the requirements of the measurement method, pre-treatment may include pre-heating, impregnation, weighing-in, pre-cleaning, or other methods of conditioning. The pre-treatment is documented by a protocol, where the NF is responsible for correct documentation.

Following pre-treatment, the sample medium is exposed to air sample at the NFs field site. The step is documented by a protocol, including e.g. medium ID, exposure begin and end time, sample amount collected, exposure standard protocol ID, and others. The NF is responsible for correctly assembling this documentation.

After exposure and transporting the sample medium back to the NF's central lab, the sample medium is prepared for analysis. This step may comprise weighing-out, medium extraction, partitioning of sample medium, or other steps as required by the method. The corresponding protocol, assembled under the responsibility of the NF, may contain parameters like medium ID, preparation time, preparation protocol, numerical preparation results, or others.

Finally, the sample extracted from the sample medium is analysed at the NF. The pertaining protocol, assembled responsibly by the NF, contains parameters such as sample medium ID, extract ID, analysis, device type and ID, numerical analysis results, and others.

All protocols of sample medium and sample extract treatment generated in the workflow are stored in machine-readable form in a sample and analysis database. Operation of this database is to meet long-term archive standards, e.g. intervals of upgrading database hard- and software, and frequent schedule for on- and off-site backups.
The NF is responsible for producing the final level 2 data product of the workflow by using the results of all 4 sample medium and sample extract treatment steps. Besides the concentration of the desired atmospheric property and standard level 2 metadata, the data product contains metadata such as sample medium and extract ID, standard procedures used, special condition flags, and others.

### 3.1.1.1 Data services and tools offered to NF for in situ data production and quality control

In order to improve data quality and assist the NF in data production, the ACTRIS surface in situ data centre unit have to offer services and data control tool, and development of required tools and procedure for data submission and production. The in situ data centre unit need to offer;

* Online portal for standardised submission of data by the NF operators to the in situ data centre unit,

* Check of meta data formats upon data submission

* Traceable documentation of data QC processes by review, accessible to NF, TC and DC

* File and meta data production tool

* Standardised sanity and consistency checks of data submitted through submission portal

* Software and digital tools for generating required data levels,

* Development and implementation of data production tools (L0 – L1 – L2) for selected types of data

* Implementation of data quality control tools and procedures developed at the DC or TCs

* Development and maintenance of tools for quality control of data, including implementation of new quality assurance criteria defined by TCs,

* Tools for performing manual quality controls in a homogeneous way at the NF,

* For the RRT branch of the online ACTRIS surface in situ data workflow, a service for testing thresholds of incoming data and instrument parameters with connected e-mail alert service, facilitating early detection and mitigation of instrument problems at the ACTRIS NFs

* For the RRT branch of the online ACTRIS surface in situ data workflow, a service for testing physical consistency between observations (closure). The reports of this service are sent to the responsible NFs in scheduled intervals.

### 1.1.1.3 General Principles for ACTRIS in situ Data curation

The relation between the various data products, pre-products, and processing steps of both online and offline ACTRIS surface in situ data workflow is depicted in the corresponding workflow diagram (see Annex III). The details concerning implementation of these workflows for individual ACTRIS variables are specified in the pertaining, variable specific data management plan and implementation plan. This implementation plan describes the data and metadata items contained in each data level, data format used, the individual operations performed in each production step between data levels, as well as data and metadata items contained in each sample handling protocol (offline workflow). The content of the data management plan and implementation plans is determined by the responsible TC in collaboration with the in situ data centre unit.
The NF is responsible for producing the final level 2 data product of the workflow by using the results of all 4 sample medium and sample extract treatment steps. Besides the concentration of the desired atmospheric property and standard level 2 metadata, the data product contains metadata such as sample medium and extract ID, standard procedures used, special condition flags, and others.

### 3.1.1.1 Data services and tools offered to NF for in situ data production and quality control

In order to improve data quality and assist the NF in data production, the ACTRIS surface in situ data centre unit have to offer services and data control tool, and development of required tools and procedure for data submission and production. The in situ data centre unit need to offer;

* Online portal for standardised submission of data by the NF operators to the in situ data centre unit,

* Check of meta data formats upon data submission

* Traceable documentation of data QC processes by review, accessible to NF, TC and DC

* File and meta data production tool

* Standardised sanity and consistency checks of data submitted through submission portal

* Software and digital tools for generating required data levels,

* Development and implementation of data production tools (L0 – L1 – L2) for selected types of data

* Implementation of data quality control tools and procedures developed at the DC or TCs

* Development and maintenance of tools for quality control of data, including implementation of new quality assurance criteria defined by TCs,

* Tools for performing manual quality controls in a homogeneous way at the NF,

* For the RRT branch of the online ACTRIS surface in situ data workflow, a service for testing thresholds of incoming data and instrument parameters with connected e-mail alert service, facilitating early detection and mitigation of instrument problems at the ACTRIS NFs

* For the RRT branch of the online ACTRIS surface in situ data workflow, a service for testing physical consistency between observations (closure). The reports of this service are sent to the responsible NFs in scheduled intervals.

### 1.1.1.3 General Principles for ACTRIS in situ Data curation

The relation between the various data products, pre-products, and processing steps of both online and offline ACTRIS surface in situ data workflow is depicted in the corresponding workflow diagram (see Annex III). The details concerning implementation of these workflows for individual ACTRIS variables are specified in the pertaining, variable specific data management plan and implementation plan. This implementation plan describes the data and metadata items contained in each data level, data format used, the individual operations performed in each production step between data levels, as well as data and metadata items contained in each sample handling protocol (offline workflow). The content of the data management plan and implementation plans is determined by the responsible TC in collaboration with the in situ data centre unit.
All data products, pre-products, and sample handling protocols, as well as all software and algorithms used in production steps, version controlled, archived following long-term archive standards, and identified in each version. Persons involved in manual data production steps are identified, as well as entity responsible for the production step. For establishing traceability, the data products and pre-products contain references to the identifiers of all (pre-)products, production tools, persons and entities involved in the whole production chain leading up to the (pre-)product.

To facilitate harmonised data products and quality, the ACTRIS DC is responsible for ensuring that all instances of a specific data production step operated in the ACTRIS network uses the same identified version at any given time. To the same end, the DC provides tools for conducting standardised manual data QC under the responsibility of the NFs. As a low-barrier tool, the surface in situ data centre unit offers a web-based data submission portal allowing interactive checks of data submissions, as well as conducting the submission upon successful check. The test include syntactic and semantic correctness and consistency of metadata and data, as well as standardised tests for outliers and spikes.

In the workflows, the TCs are responsible for QA of instruments and analysis methods in the network, and also responsible for specifying QC procedures conducted in the network, for data QC in collaboration with the surface in situ DC unit. Examples for instrument and analysis QA measures are on-site comparisons to a standard, centralised off-site comparisons, and laboratory round-robin exercises. Together with the responsible data centre unit, the TCs are responsible for specifying data and metadata items documenting these QA measures in a harmonised way. The TCs are also responsible for collecting the data and metadata items when conducting QA measures, and storing them in a QA result database in machine-readable form. From here, the QA measure results are joined with ACTRIS variable data during data production. Based on the generic data production workflows described above, the ACTRIS surface in situ DC node supports implementation of data workflows for new surface in situ variables as agreed by the consortium

### 3.1.1.2 Potential campaign service for ACTRIS in situ data

The data centre need to offer a service for campaigns at the NF sites. A general procedure needs to be offered for this through SAMU, described in section 4.7 on page 33.

## 3.1.2 Data curation service and tools of ACTRIS aerosol remote sensing data

All ACTRIS aerosol profile variables are listed in Annex I, associated with instrument type and potential for real-real-time (RRT) data. ACTRIS DC must provide support to the aerosol profile data originator for centralized data processing through the common standardized automatic analysis software developed in previous projects toward the ACTRIS RI, the Single Calculus Chain (SCC). The Single Calculus Chain (SCC) is an open source software for analysing aerosol LIDAR data to obtain aerosol optical property profiles from raw data. The SCC is an official EARLINET developed tool to accomplish the fundamental need of any coordinated LIDAR network to have an optimized and automatic tool providing high-quality aerosol property profiles. Main concepts at the base of the SCC are automatization and full traceability of quality-assured aerosol optical products.

Two other algorithms are also implemented in ACTRIS DC:
All data products, pre-products, and sample handling protocols, as well as all software and algorithms used in production steps, version controlled, archived following long-term archive standards, and identified in each version. Persons involved in manual data production steps are identified, as well as entity responsible for the production step. For establishing traceability, the data products and pre-products contain references to the identifiers of all (pre-)products, production tools, persons and entities involved in the whole production chain leading up to the (pre-)product.

To facilitate harmonised data products and quality, the ACTRIS DC is responsible for ensuring that all instances of a specific data production step operated in the ACTRIS network uses the same identified version at any given time. To the same end, the DC provides tools for conducting standardised manual data QC under the responsibility of the NFs. As a low-barrier tool, the surface in situ data centre unit offers a web-based data submission portal allowing interactive checks of data submissions, as well as conducting the submission upon successful check. The test include syntactic and semantic correctness and consistency of metadata and data, as well as standardised tests for outliers and spikes.

In the workflows, the TCs are responsible for QA of instruments and analysis methods in the network, and also responsible for specifying QC procedures conducted in the network, for data QC in collaboration with the surface in situ DC unit. Examples for instrument and analysis QA measures are on-site comparisons to a standard, centralised off-site comparisons, and laboratory round-robin exercises. Together with the responsible data centre unit, the TCs are responsible for specifying data and metadata items documenting these QA measures in a harmonised way. The TCs are also responsible for collecting the data and metadata items when conducting QA measures, and storing them in a QA result database in machine-readable form. From here, the QA measure results are joined with ACTRIS variable data during data production. Based on the generic data production workflows described above, the ACTRIS surface in situ DC node supports implementation of data workflows for new surface in situ variables as agreed by the consortium

### 3.1.1.2 Potential campaign service for ACTRIS in situ data

The data centre need to offer a service for campaigns at the NF sites. A general procedure needs to be offered for this through SAMU, described in section 4.7 on page 33.

## 3.1.2 Data curation service and tools of ACTRIS aerosol remote sensing data

All ACTRIS aerosol profile variables are listed in Annex I, associated with instrument type and potential for real-real-time (RRT) data. ACTRIS DC must provide support to the aerosol profile data originator for centralized data processing through the common standardized automatic analysis software developed in previous projects toward the ACTRIS RI, the Single Calculus Chain (SCC). The Single Calculus Chain (SCC) is an open source software for analysing aerosol LIDAR data to obtain aerosol optical property profiles from raw data. The SCC is an official EARLINET developed tool to accomplish the fundamental need of any coordinated LIDAR network to have an optimized and automatic tool providing high-quality aerosol property profiles. Main concepts at the base of the SCC are automatization and full traceability of quality-assured aerosol optical products.

Two other algorithms are also implemented in ACTRIS DC:
* The AERONET-ACTRIS processing stream, which process the photometer data from ACTRIS European sites. It produces the radiances (almucantar, principal plane, polarized principal plane) and the aerosol optical depth. All this processing stream is fully controlled inside the ACTRIS RI.

* The GARRLiC (Generalized Aerosol Retrieval from Radiometer and Lidar Combined data), which simultaneously inverts coincident LIDAR and radiometer observations to retrieve aerosol optical and physical properties (profile and column).

The data curation workflows is suitable for the provision in RRT and RRT, following the same steps and procedures of the standard processing. RRT/RRT delivery of not fully quality assured data can be possible for stations if the steps for collecting, transferring and submitting data to the processing suite are fully automatized.

The ACTRIS data levels is described in Figure 1. A more detailed description of data levels for aerosol profile data is following, in agreement with the general description:

* **Level 0:** raw data as produced by the instrument, all main and instrument status parameters provided by instrument, brought to a common, well-defined data format. Discovery, use, provenance, and configuration metadata attached, including all information needed for further data production, as far as known at stations level (e.g. QC metadata). Time and temporal resolution as native to the instrument.

* **Level 1:** not fully quality controlled data. This level of data contains both pre-processed LIDAR data, i.e. a step in between the raw signal (Level 0 data stored at each station) and the optical properties, and optical properties themselves. At this level, some instrumental corrections are already implemented and annotated into the data for both pre-processed data and optical properties. The instrumental corrections are based on the inputs reported in an agreed machine readable format by the TC and provided to DC.

* **Level 2:** fully quality controlled data generated from Level 1 data. At this level, all QC are completed and fully reported into the data. Instrumental corrections and annotation are completed: quality assurance of the instrument is complete based on scheduled intercomparison and check-up of the instruments. On the other hand the feedback mechanism of QC could suggest further specific instrumental check, on which basis new technical annotations/corrections were needed and annotated in this fully QC data level. Fully QC aerosol optical properties are reported as well in this level: for these products Level 2 pre-processed data are used and the needed inputs in terms of atmospheric density and temperature if needed are updated using reanalysis models.

#### 1.1.1.4 Data curation service of ACTRIS aerosol profile data

Raw data collected at the NF in the original acquisition data format are transcribed in a homogeneous and agreed netCDF data format to the aerosol remote sensing processing suite at the ACTRIS DC. All information needed for the steps forward in the processing chain are annotated into the file.

The raw data are submitted to the SCC by the Data Originator through SCC web interface. Through the SCC interface, Data Originator can interact with the SCC database, which is a relational database which handles the large number of input parameters needed for the retrievals of aerosol optical products from LIDAR signal. Two different types of parameters are needed: experimental (which are mainly used to correct instrumental effects) and configurational (which define the way to apply a particular analysis
* The AERONET-ACTRIS processing stream, which process the photometer data from ACTRIS European sites. It produces the radiances (almucantar, principal plane, polarized principal plane) and the aerosol optical depth. All this processing stream is fully controlled inside the ACTRIS RI.

* The GARRLiC (Generalized Aerosol Retrieval from Radiometer and Lidar Combined data), which simultaneously inverts coincident LIDAR and radiometer observations to retrieve aerosol optical and physical properties (profile and column).

The data curation workflows is suitable for the provision in RRT and RRT, following the same steps and procedures of the standard processing. RRT/RRT delivery of not fully quality assured data can be possible for stations if the steps for collecting, transferring and submitting data to the processing suite are fully automatized.

The ACTRIS data levels is described in Figure 1. A more detailed description of data levels for aerosol profile data is following, in agreement with the general description:

* **Level 0:** raw data as produced by the instrument, all main and instrument status parameters provided by instrument, brought to a common, well-defined data format. Discovery, use, provenance, and configuration metadata attached, including all information needed for further data production, as far as known at stations level (e.g. QC metadata). Time and temporal resolution as native to the instrument.

* **Level 1:** not fully quality controlled data. This level of data contains both pre-processed LIDAR data, i.e. a step in between the raw signal (Level 0 data stored at each station) and the optical properties, and optical properties themselves. At this level, some instrumental corrections are already implemented and annotated into the data for both pre-processed data and optical properties. The instrumental corrections are based on the inputs reported in an agreed machine readable format by the TC and provided to DC.

* **Level 2:** fully quality controlled data generated from Level 1 data. At this level, all QC are completed and fully reported into the data. Instrumental corrections and annotation are completed: quality assurance of the instrument is complete based on scheduled intercomparison and check-up of the instruments. On the other hand the feedback mechanism of QC could suggest further specific instrumental check, on which basis new technical annotations/corrections were needed and annotated in this fully QC data level. Fully QC aerosol optical properties are reported as well in this level: for these products Level 2 pre-processed data are used and the needed inputs in terms of atmospheric density and temperature if needed are updated using reanalysis models.

#### 1.1.1.4 Data curation service of ACTRIS aerosol profile data

Raw data collected at the NF in the original acquisition data format are transcribed in a homogeneous and agreed netCDF data format to the aerosol remote sensing processing suite at the ACTRIS DC. All information needed for the steps forward in the processing chain are annotated into the file.

The raw data are submitted to the SCC by the Data Originator through SCC web interface. Through the SCC interface, Data Originator can interact with the SCC database, which is a relational database which handles the large number of input parameters needed for the retrievals of aerosol optical products from LIDAR signal. Two different types of parameters are needed: experimental (which are mainly used to correct instrumental effects) and configurational (which define the way to apply a particular analysis
procedure). This information is the outcome of the QA and is provided to the DC by the CARS. The SCC
web interface here and at the other processing steps, allows the monitoring of the processing status of
each measurement.

After the configuration set-up for the processing the raw signals are processed through the **Pre-processor module (ELPP: EARLINET Lidar Pre-Processor)**. The ELPP module implements the corrections to be applied to the raw LIDAR signals before they can be used to derive aerosol optical properties. Following the QA procedures, some instrumental effects are corrected. Level 1 pre-processed data are stored in internal SCC archive and on ACTRIS DC.

Level 1 pre-processed data are then processed through the **Optical processor module (ELDA: EARLINET Lidar Data Analyser)**. ELDA enables the retrieval of particle backscatter coefficients, the calculation of particle extinction coefficient and finally the computation of particle and volume linear depolarization profiles, multi-wavelength and layer products. All the optical products are written in netCDF files in the agreed DC format and constitute the Level 1 processed data.

For aerosol remote sensing NFs which are also equipped with microwave radiometer and cloud radar, the level 1 pre-processed data are also an input data for the cloud profile data unit.

Then the data are submitted to the ACTRIS aerosol remote sensing DC database. **On fly QC procedures** run directly during the submission phase. These procedures control that the file content respect to the file structure as agreed. Additional scientific controls check that all mandatory products are reported into the files. All data passing the on-fly QC are uploaded on the DC as Level 1 products. **Off-line QC procedures** are run systematically every 3 months. The data originator receives feedback of the outcome of the QC. This feedback mechanism potentially allow to discover and address instrumental issues, with links to the TC. All the data compliant to all the QC requirements (both pre-processed and processed data) are made available as Level 2 data.

Finally, the ACTRIS DC have to offer different products resulting from the processing at DC itself of Level 2 LIDAR and photometer data collected at the aerosol remote sensing NFs. The ACTRIS datacentre offers in this way the possibility to ACTRIS users to access among the others to profiles of aerosol volume concentration profiles which is potentially of great interest for different users, like modellers, and local, national and international authorities.

### 3.1.2.1 Data services and tools offered to NF for aerosol profile data production and quality control

In order to improve data quality and assist the NF in data production, the ACTRIS aerosol remote sensing data unit offers services and data control tool, and development of required tools and procedure for data submission and production. The ACTRIS aerosol remote sensing data unit needs to offer;

* Online portal for standardised submission of data by the NF operators to the aerosol profile data centre unit,

* Automatic check of meta data formats upon data submission

* Automatic standardised sanity and consistency checks of data submitted through submission portal

* Implementation of data quality control tools and procedures developed at the DC or TCs
procedure). This information is the outcome of the QA and is provided to the DC by the CARS. The SCC
web interface here and at the other processing steps, allows the monitoring of the processing status of
each measurement.

After the configuration set-up for the processing the raw signals are processed through the **Pre-processor module (ELPP: EARLINET Lidar Pre-Processor)**. The ELPP module implements the corrections to be applied to the raw LIDAR signals before they can be used to derive aerosol optical properties. Following the QA procedures, some instrumental effects are corrected. Level 1 pre-processed data are stored in internal SCC archive and on ACTRIS DC.

Level 1 pre-processed data are then processed through the **Optical processor module (ELDA: EARLINET Lidar Data Analyser)**. ELDA enables the retrieval of particle backscatter coefficients, the calculation of particle extinction coefficient and finally the computation of particle and volume linear depolarization profiles, multi-wavelength and layer products. All the optical products are written in netCDF files in the agreed DC format and constitute the Level 1 processed data.

For aerosol remote sensing NFs which are also equipped with microwave radiometer and cloud radar, the level 1 pre-processed data are also an input data for the cloud profile data unit.

Then the data are submitted to the ACTRIS aerosol remote sensing DC database. **On fly QC procedures** run directly during the submission phase. These procedures control that the file content respect to the file structure as agreed. Additional scientific controls check that all mandatory products are reported into the files. All data passing the on-fly QC are uploaded on the DC as Level 1 products. **Off-line QC procedures** are run systematically every 3 months. The data originator receives feedback of the outcome of the QC. This feedback mechanism potentially allow to discover and address instrumental issues, with links to the TC. All the data compliant to all the QC requirements (both pre-processed and processed data) are made available as Level 2 data.

Finally, the ACTRIS DC have to offer different products resulting from the processing at DC itself of Level 2 LIDAR and photometer data collected at the aerosol remote sensing NFs. The ACTRIS datacentre offers in this way the possibility to ACTRIS users to access among the others to profiles of aerosol volume concentration profiles which is potentially of great interest for different users, like modellers, and local, national and international authorities.

### 3.1.2.1 Data services and tools offered to NF for aerosol profile data production and quality control

In order to improve data quality and assist the NF in data production, the ACTRIS aerosol remote sensing data unit offers services and data control tool, and development of required tools and procedure for data submission and production. The ACTRIS aerosol remote sensing data unit needs to offer;

* Online portal for standardised submission of data by the NF operators to the aerosol profile data centre unit,

* Automatic check of meta data formats upon data submission

* Automatic standardised sanity and consistency checks of data submitted through submission portal

* Implementation of data quality control tools and procedures developed at the DC or TCs
* Development and maintenance of tools for quality control of data, including implementation of new quality assurance/control criteria defined by TCs,

* Feedback mechanisms about QC to Data originator

* Processing suite for the processing of aerosol LIDAR data for the retrieval of all the described above products

* Development and maintenance of processing chain for aerosol LIDAR data, including implementation of new products in agreement with TCs,

### 1.1.1.5 General Principles for ACTRIS aerosol profiles Data curation

The relation between the various data products, pre-products, and processing steps of both ACTRIS aerosol profile data workflow is depicted in the corresponding workflow diagram (see Annex III). The details concerning implementation of these workflows for individual ACTRIS variables are specified in the pertaining, variable specific data managements plan and implementation plan. This implementation plan describes the data and metadata items contained in each data level, data format used, the individual operations performed in each production step between data levels, as well as data and metadata items contained in each sample handling protocol. The content of the data managements plan and implementation plans is determined by the responsible TC in collaboration with the aerosol profiles data centre unit.

All data products, pre-products, and sample handling protocols, as well as all software and algorithms used in production steps, version controlled, archived following long-term archive standards, and identified in each version. Persons involved in data production steps are identified, as well as entity responsible for the production step. For establishing traceability, the data products and pre-products contain references to the identifiers of all (pre-)products, production tools, persons and entities involved in the whole production chain leading up to the (pre-)product.

To facilitate harmonised data products and quality, the ACTRIS DC is responsible for ensuring that all instances of a specific data production step operated in the ACTRIS network uses the same identified version at any given time. To the same end, the DC provides tools for conducting standardised manual data QC under the responsibility of the NFs. As a low-barrier tool, the surface in situ data centre unit offers a web-based data submission portal allowing interactive checks of data submissions, as well as conducting the submission upon successful check. The test include syntactic and semantic correctness and consistency of metadata and data, as well as standardised tests for outliers and spikes.

In the workflows, the TCs are responsible for QA of instruments and analysis methods in the network, and also responsible for specifying QC procedures conducted in the network, for data QC in collaboration with aerosol profiles DC unit. Examples for instrument and analysis QA measures are on-site comparisons to a reference instrument and on-site tests. Together with the responsible data centre unit, the TCs are responsible for specifying data and metadata items documenting these QA measures in a harmonised way. The TCs are also responsible for collecting the data and metadata items when conducting QA measures, and storing them in a QA result database in machine-readable form. From here, the QA measure results are joined with ACTRIS variable data during data production.
* Development and maintenance of tools for quality control of data, including implementation of new quality assurance/control criteria defined by TCs,

* Feedback mechanisms about QC to Data originator

* Processing suite for the processing of aerosol LIDAR data for the retrieval of all the described above products

* Development and maintenance of processing chain for aerosol LIDAR data, including implementation of new products in agreement with TCs,

### 1.1.1.5 General Principles for ACTRIS aerosol profiles Data curation

The relation between the various data products, pre-products, and processing steps of both ACTRIS aerosol profile data workflow is depicted in the corresponding workflow diagram (see Annex III). The details concerning implementation of these workflows for individual ACTRIS variables are specified in the pertaining, variable specific data managements plan and implementation plan. This implementation plan describes the data and metadata items contained in each data level, data format used, the individual operations performed in each production step between data levels, as well as data and metadata items contained in each sample handling protocol. The content of the data managements plan and implementation plans is determined by the responsible TC in collaboration with the aerosol profiles data centre unit.

All data products, pre-products, and sample handling protocols, as well as all software and algorithms used in production steps, version controlled, archived following long-term archive standards, and identified in each version. Persons involved in data production steps are identified, as well as entity responsible for the production step. For establishing traceability, the data products and pre-products contain references to the identifiers of all (pre-)products, production tools, persons and entities involved in the whole production chain leading up to the (pre-)product.

To facilitate harmonised data products and quality, the ACTRIS DC is responsible for ensuring that all instances of a specific data production step operated in the ACTRIS network uses the same identified version at any given time. To the same end, the DC provides tools for conducting standardised manual data QC under the responsibility of the NFs. As a low-barrier tool, the surface in situ data centre unit offers a web-based data submission portal allowing interactive checks of data submissions, as well as conducting the submission upon successful check. The test include syntactic and semantic correctness and consistency of metadata and data, as well as standardised tests for outliers and spikes.

In the workflows, the TCs are responsible for QA of instruments and analysis methods in the network, and also responsible for specifying QC procedures conducted in the network, for data QC in collaboration with aerosol profiles DC unit. Examples for instrument and analysis QA measures are on-site comparisons to a reference instrument and on-site tests. Together with the responsible data centre unit, the TCs are responsible for specifying data and metadata items documenting these QA measures in a harmonised way. The TCs are also responsible for collecting the data and metadata items when conducting QA measures, and storing them in a QA result database in machine-readable form. From here, the QA measure results are joined with ACTRIS variable data during data production.
Based on the generic data production workflows described above, the ACTRIS aerosol profile DC node supports implementation of data workflows for new aerosol profiling variables as agreed by the consortium

### 3.1.2.2 Potential campaign service for ACTRIS aerosol profiles data

The data centre need to offer a service for campaigns at the NF sites. A general procedure needs to be offered for this through SAMU, described in section 4.7 on page 33.

### 3.1.3 Data curation service and tools of ACTRIS cloud remote sensing data

All ACTRIS cloud profile variables are listed in Annex I, associated with their combination of instrument types, and the potential for being produced in rear-real-time (RRT) or real-real-time (RRT). The ACTRIS DC shall provide to the cloud profile data originator support for centralized data processing through the common standardized automated processing software developed in previous projects for the ACTRIS RI, the Cloudnet processing scheme. The Cloudnet processing scheme is open source software designed for combining cloud radar and LIDAR observations in order to obtain vertical profiles of cloud parameters. The Cloudnet scheme provides the necessary tools for full traceability of harmonized data processing, automated quality control and product generation.

The data curation workflow (reported in Annex 3) follows the automated standard processing and enables RRT and RRT delivery of cloud profile variables.

The ACTRIS data levels are described in Figure 1. A more detailed description of data levels pertaining to cloud profile data follow, in agreement with the general description:

* Level 0: raw data as produced by the instrument, including instrument status parameters provided by instrument, brought to a common, well-defined data format. Discovery, use, provenance, and configuration metadata attached, including all information needed for further data production, as far as is known at station level (e.g. QC metadata). Time and temporal resolution as native to the instrument.

* Level 1: processing of Level 0 instrument data, and their subsequent combination to provide a single synergistic product on a well-defined time-height grid. All individual observations are pre-processed and quality-checked. The synergistic product is the basis from which all ACTRIS cloud products are created, and provides the harmonized dataset that contains all instrument uncertainties and quality control flags for propagation through retrieval algorithms, as well as providing the underlying target identification for retrievals to operate on.

* Level 2: Cloud variables generated from Level 1 data, including uncertainties and product status.

#### 3.1.3.1 Data curation service of ACTRIS cloud profile data

Raw data collected at the NF in the original data acquisition format are transcribed to an agreed harmonized netCDF data format suitable for ingestion by the Cloudnet processing scheme. Data from each instrument is pre-processed separately to identify and remove artefacts, and a calibration factor applied as required, supplied by the responsible TC. The pre-processed single-instrument level 0 data are made available for review and possible re-calibration by the responsible TC. The TC organises the review process,
Based on the generic data production workflows described above, the ACTRIS aerosol profile DC node supports implementation of data workflows for new aerosol profiling variables as agreed by the consortium

### 3.1.2.2 Potential campaign service for ACTRIS aerosol profiles data

The data centre need to offer a service for campaigns at the NF sites. A general procedure needs to be offered for this through SAMU, described in section 4.7 on page 33.

### 3.1.3 Data curation service and tools of ACTRIS cloud remote sensing data

All ACTRIS cloud profile variables are listed in Annex I, associated with their combination of instrument types, and the potential for being produced in rear-real-time (RRT) or real-real-time (RRT). The ACTRIS DC shall provide to the cloud profile data originator support for centralized data processing through the common standardized automated processing software developed in previous projects for the ACTRIS RI, the Cloudnet processing scheme. The Cloudnet processing scheme is open source software designed for combining cloud radar and LIDAR observations in order to obtain vertical profiles of cloud parameters. The Cloudnet scheme provides the necessary tools for full traceability of harmonized data processing, automated quality control and product generation.

The data curation workflow (reported in Annex 3) follows the automated standard processing and enables RRT and RRT delivery of cloud profile variables.

The ACTRIS data levels are described in Figure 1. A more detailed description of data levels pertaining to cloud profile data follow, in agreement with the general description:

* Level 0: raw data as produced by the instrument, including instrument status parameters provided by instrument, brought to a common, well-defined data format. Discovery, use, provenance, and configuration metadata attached, including all information needed for further data production, as far as is known at station level (e.g. QC metadata). Time and temporal resolution as native to the instrument.

* Level 1: processing of Level 0 instrument data, and their subsequent combination to provide a single synergistic product on a well-defined time-height grid. All individual observations are pre-processed and quality-checked. The synergistic product is the basis from which all ACTRIS cloud products are created, and provides the harmonized dataset that contains all instrument uncertainties and quality control flags for propagation through retrieval algorithms, as well as providing the underlying target identification for retrievals to operate on.

* Level 2: Cloud variables generated from Level 1 data, including uncertainties and product status.

#### 3.1.3.1 Data curation service of ACTRIS cloud profile data

Raw data collected at the NF in the original data acquisition format are transcribed to an agreed harmonized netCDF data format suitable for ingestion by the Cloudnet processing scheme. Data from each instrument is pre-processed separately to identify and remove artefacts, and a calibration factor applied as required, supplied by the responsible TC. The pre-processed single-instrument level 0 data are made available for review and possible re-calibration by the responsible TC. The TC organises the review process,
defines the review criteria, and performs re-calibration if required. All information necessary for the
Cloudnet processing chain to operate is checked or included at this stage.

After configuration set up for the specific instrument combination, the pre-processed instrument data is
then combined using the target categorisation module of the Cloudnet processing scheme to produce the
level 1 data. This module also calculates and applies radar attenuation parameters, together with a quality
status reflecting the instrument performance and the impact of the atmospheric conditions on the
measurements.

Level 2 products are generated from the level 1 synthesis product with all uncertainties, quality status, and metadata propagated from level 1. Cloud remote sensing NFs which are also equipped with aerosol profiling capabilities can then generate additional synthesis products combining cloud remote sensing products with level 1 aerosol remote sensing data.

Level 3 climatological and composite datasets are obtained using Level 2 cloud products through monthly and yearly aggregation. Datasets are composited by seasonal, diurnal, precipitation, omega-at-500 mb (vertical motion) and other suitable parameters. Metrics containing mean values and the distribution are reported. Level 3 datasets are also used in numerical weather prediction (NWP) and climate model evaluation.

The entire processing chain, from level 0 to level 3 (including model evaluation), can operate in two QC
streams:

1. **Automatic QC**: algorithmic inspection of data for outliers, spikes, and automatically identifiable instrument malfunctions. Instruments receive automated or the previous manual calibration values. This stream is used for RRT/RRTdata.

2. **Manual QC**: inspection of data by an identified person under the responsibility of the NF. The additional manual QC includes extra tests for specific instrument and atmospheric issues that may be location-specific (radio interference, fog, and insects) and verification of instrument QC such as re-calibration. Manual QC is applied at least at an annual frequency.

3.1.3.2 Data services and tools offered to NF for cloud profile data production and quality control

In order to improve data quality and assist the NF in data production, the ACTRIS cloud remote sensing data unit offers data tools and services, and the development of the required tools and procedures for data submission and production. The ACTRIS cloud remote sensing data unit shall offer;

* Online portal for standardised submission of data by the NF operators to the cloud profile data centre unit,

* Standardised sanity and consistency checks of data on submission

* Implementation of data quality control tools and procedures developed at the DC or TCs

* Development and maintenance of tools for quality control of data, including implementation of new quality assurance/control criteria defined by TCs,

* Mechanisms to feedback data QC issues to Data originator

* Processing suite for the retrieval of all cloud products (L0 - L1 - L2)

* Development and maintenance of processing chain for cloud remote sensing data, including implementation of new products in agreement with TCs
defines the review criteria, and performs re-calibration if required. All information necessary for the
Cloudnet processing chain to operate is checked or included at this stage.

After configuration set up for the specific instrument combination, the pre-processed instrument data is
then combined using the target categorisation module of the Cloudnet processing scheme to produce the
level 1 data. This module also calculates and applies radar attenuation parameters, together with a quality
status reflecting the instrument performance and the impact of the atmospheric conditions on the
measurements.

Level 2 products are generated from the level 1 synthesis product with all uncertainties, quality status, and metadata propagated from level 1. Cloud remote sensing NFs which are also equipped with aerosol profiling capabilities can then generate additional synthesis products combining cloud remote sensing products with level 1 aerosol remote sensing data.

Level 3 climatological and composite datasets are obtained using Level 2 cloud products through monthly and yearly aggregation. Datasets are composited by seasonal, diurnal, precipitation, omega-at-500 mb (vertical motion) and other suitable parameters. Metrics containing mean values and the distribution are reported. Level 3 datasets are also used in numerical weather prediction (NWP) and climate model evaluation.

The entire processing chain, from level 0 to level 3 (including model evaluation), can operate in two QC
streams:

1. **Automatic QC:** algorithmic inspection of data for outliers, spikes, and automatically identifiable instrument malfunctions. Instruments receive automated or the previous manual calibration values. This stream is used for RRT/RRTdata.

2. **Manual QC:** inspection of data by an identified person under the responsibility of the NF. The additional manual QC includes extra tests for specific instrument and atmospheric issues that may be location-specific (radio interference, fog, and insects) and verification of instrument QC such as re-calibration. Manual QC is applied at least at an annual frequency.

3.1.3.2 Data services and tools offered to NF for cloud profile data production and quality control

In order to improve data quality and assist the NF in data production, the ACTRIS cloud remote sensing data unit offers data tools and services, and the development of the required tools and procedures for data submission and production. The ACTRIS cloud remote sensing data unit shall offer;

* Online portal for standardised submission of data by the NF operators to the cloud profile data centre unit,

* Standardised sanity and consistency checks of data on submission

* Implementation of data quality control tools and procedures developed at the DC or TCs

* Development and maintenance of tools for quality control of data, including implementation of new quality assurance/control criteria defined by TCs,

* Mechanisms to feedback data QC issues to Data originator

* Processing suite for the retrieval of all cloud products (L0 - L1 - L2)

* Development and maintenance of processing chain for cloud remote sensing data, including implementation of new products in agreement with TCs
### 3.1.3.3 General Principles for ACTRIS cloud profile data curation

The relationship between the various instruments and processing steps in the ACTRIS cloud profile data workflow is depicted in the corresponding workflow diagram (see Annex III). The details concerning implementation of these workflows for individual ACTRIS variables are specified in the pertaining, variable-specific data management plan and implementation plan. This implementation plan describes the data and metadata items contained in each data level, the data format used, the individual operations performed at each production step at every data level, and the items contained in each sample handling protocol. The content of the data management plan and implementation plan is determined by the responsible TC in collaboration with the cloud profile data centre unit.

All data products, pre-products, and sample handling protocols, as well as all software and algorithms used in production steps, version controlled, archived following long-term archive standards, and identified in each version. Persons involved in data production steps are identified, as well as entity responsible for the production step. For establishing traceability, the data products and pre-products contain references to the identifiers of all instruments, (pre-)products, production tools, persons and entities involved in the whole production chain leading up to the (pre-)product.

To facilitate harmonised data products and quality, the ACTRIS DC is responsible for ensuring that all instances of a specific data production step operated in the ACTRIS network uses an identifiable version at any given time. To the same end, the DC provides tools for conducting standardised manual data QC under the responsibility of the NFs, including syntactic and semantic correctness and consistency of metadata and data, as well as standardised tests for outliers and spikes.

In the workflow, the TCs are responsible for QA of instruments and analysis methods in the network, and also responsible for specifying QC procedures conducted in the network, for data QC in collaboration with the cloud profile DC unit. Examples for instrument and analysis QA measures are routine calibration, and on-site comparisons to a reference instrument. Together with the responsible data centre unit, the TCs are responsible for specifying data and metadata items documenting these QA measures in a harmonised way. The TCs are also responsible for collecting the data and metadata items when conducting QA measures, and storing them in a QA result database in machine-readable form. From here, the QA measure results and calibrations are joined with ACTRIS variable data during data production.

Based on the generic data production workflows described above, the ACTRIS cloud profile DC node supports implementation of data workflows for new cloud profiling variables as agreed by the consortium

### 3.1.3.4 Potential campaign service for ACTRIS cloud profile data

The data centre need to offer a service for campaigns at the NF sites. A general procedure needs to be offered for this through SAMU, described in section 4.7 on page 33.

### 3.1.4 Data curation service and tools for ACTRIS trace gas remote sensing data

Trace gas remote sensing data can be issued from four types of instruments: FTIR, UV-VIS, SAOZ and LIDAR and produced by using a specific data production chain. According to the type of instrument the data production is performed either by NFs or TCs while ACTRIS DC must be in charge of data curation for Level 2 data as well as tools and services for data producers and
### 3.1.3.3 General Principles for ACTRIS cloud profile data curation

The relationship between the various instruments and processing steps in the ACTRIS cloud profile data workflow is depicted in the corresponding workflow diagram (see Annex III). The details concerning implementation of these workflows for individual ACTRIS variables are specified in the pertaining, variable-specific data management plan and implementation plan. This implementation plan describes the data and metadata items contained in each data level, the data format used, the individual operations performed at each production step at every data level, and the items contained in each sample handling protocol. The content of the data management plan and implementation plan is determined by the responsible TC in collaboration with the cloud profile data centre unit.

All data products, pre-products, and sample handling protocols, as well as all software and algorithms used in production steps, version controlled, archived following long-term archive standards, and identified in each version. Persons involved in data production steps are identified, as well as entity responsible for the production step. For establishing traceability, the data products and pre-products contain references to the identifiers of all instruments, (pre-)products, production tools, persons and entities involved in the whole production chain leading up to the (pre-)product.

To facilitate harmonised data products and quality, the ACTRIS DC is responsible for ensuring that all instances of a specific data production step operated in the ACTRIS network uses an identifiable version at any given time. To the same end, the DC provides tools for conducting standardised manual data QC under the responsibility of the NFs, including syntactic and semantic correctness and consistency of metadata and data, as well as standardised tests for outliers and spikes.

In the workflow, the TCs are responsible for QA of instruments and analysis methods in the network, and also responsible for specifying QC procedures conducted in the network, for data QC in collaboration with the cloud profile DC unit. Examples for instrument and analysis QA measures are routine calibration, and on-site comparisons to a reference instrument. Together with the responsible data centre unit, the TCs are responsible for specifying data and metadata items documenting these QA measures in a harmonised way. The TCs are also responsible for collecting the data and metadata items when conducting QA measures, and storing them in a QA result database in machine-readable form. From here, the QA measure results and calibrations are joined with ACTRIS variable data during data production.

Based on the generic data production workflows described above, the ACTRIS cloud profile DC node supports implementation of data workflows for new cloud profiling variables as agreed by the consortium

### 3.1.3.4 Potential campaign service for ACTRIS cloud profile data

The data centre need to offer a service for campaigns at the NF sites. A general procedure needs to be offered for this through SAMU, described in section 4.7 on page 33.

### 3.1.4 Data curation service and tools for ACTRIS trace gas remote sensing data

Trace gas remote sensing data can be issued from four types of instruments: FTIR, UV-VIS, SAOZ and LIDAR and produced by using a specific data production chain. According to the type of instrument the data production is performed either by NFs or TCs while ACTRIS DC must be in charge of data curation for Level 2 data as well as tools and services for data producers and
users. The required ACTRIS data workflow for these data and variables are still under
discussion between TC, DC and requirements to NF. This work will proceed and clarification of
the requirements to the DC will be made in 2018.

3.1.5 Data curation service of ACTRIS atmospheric simulation chamber data

**3.1.5.1 Overview of the data production chain of ACTRIS atmospheric simulation chamber data**

Data produced by simulation chamber experiments are diverse and are organized within three databases:

* The Database of Atmospheric Simulation Chamber Studies (DASCS): This database provides a compilation of experimental and modelled data obtained from experiments in simulation chambers. These experiments can be used to further understanding of the atmospheric processes involved in air pollution and climate change, as well as their impact on health and cultural heritage. These data are highly useful for the development and the validation of atmospheric models.

* The Library of Analytical Resources (LAR): This database provides infrared, UV and mass spectra of atmospheric key species as well as mass spectra of derivatives at mid to high resolutions. Most of the spectra are calibrated to allow for quantification of species. The specificity of this library is that it focuses on atmospheric species and provides spectra of complex molecules which cannot be found elsewhere, some of them being synthesized as they are not commercially available.

* The Library of Advanced Data Products (LADP): This database provides different types of mature and high level products of chamber experiments which are very useful for researchers working on atmospheric observations, as well as atmospheric model development and validation. It includes data products for the development of chemical mechanisms in atmospheric models and for the retrieval of satellite data and for radiative transfer modelling as well as tools to generate oxidation schemes which are very useful to interpret field measurements as well as laboratory studies.

Following the ACTRIS data levels described in Figure 1, a more detailed description of data levels for atmospheric simulation chamber data is as follows:

* Level 0: raw data as provided by the instruments, with metadata attached. These data are typically time series of measured parameters during the course of the experiment.

* Level 1: Time series of the targeted properties (for example trace gas concentration, aerosol mass ...). These data are obtained from level 0 data after calibration of the instrument. For base instrumentation, calibrations are performed at the TC or following procedure recommended by the TC. For specific instrumentation, for which there is no standard procedure provided by TC, calibrations are performed at the NF following their own procedure.

* Level 2: Approved and fully quality controlled time series of the targeted properties. This quality control includes data gathering from different instruments and check for internal consistency and disregard of invalid data. Chambers characteristics, experimental protocol and metadata are attached. These data are produced by NF and are made available in the DASCS.

* Level 2.5: Approved and fully quality controlled time series of the targeted properties after corrections for wall losses and dilution have been applied. Chambers characteristics, experimental protocol and
users. The required ACTRIS data workflow for these data and variables are still under
discussion between TC, DC and requirements to NF. This work will proceed and clarification of
the requirements to the DC will be made in 2018.

3.1.5 Data curation service of ACTRIS atmospheric simulation chamber data

**3.1.5.1 Overview of the data production chain of ACTRIS atmospheric simulation chamber data**

Data produced by simulation chamber experiments are diverse and are organized within three databases:

* The Database of Atmospheric Simulation Chamber Studies (DASCS): This database provides a compilation of experimental and modelled data obtained from experiments in simulation chambers. These experiments can be used to further understanding of the atmospheric processes involved in air pollution and climate change, as well as their impact on health and cultural heritage. These data are highly useful for the development and the validation of atmospheric models.

* The Library of Analytical Resources (LAR): This database provides infrared, UV and mass spectra of atmospheric key species as well as mass spectra of derivatives at mid to high resolutions. Most of the spectra are calibrated to allow for quantification of species. The specificity of this library is that it focuses on atmospheric species and provides spectra of complex molecules which cannot be found elsewhere, some of them being synthesized as they are not commercially available.

* The Library of Advanced Data Products (LADP): This database provides different types of mature and high level products of chamber experiments which are very useful for researchers working on atmospheric observations, as well as atmospheric model development and validation. It includes data products for the development of chemical mechanisms in atmospheric models and for the retrieval of satellite data and for radiative transfer modelling as well as tools to generate oxidation schemes which are very useful to interpret field measurements as well as laboratory studies.

Following the ACTRIS data levels described in Figure 1, a more detailed description of data levels for atmospheric simulation chamber data is as follows:

* Level 0: raw data as provided by the instruments, with metadata attached. These data are typically time series of measured parameters during the course of the experiment.

* Level 1: Time series of the targeted properties (for example trace gas concentration, aerosol mass ...). These data are obtained from level 0 data after calibration of the instrument. For base instrumentation, calibrations are performed at the TC or following procedure recommended by the TC. For specific instrumentation, for which there is no standard procedure provided by TC, calibrations are performed at the NF following their own procedure.

* Level 2: Approved and fully quality controlled time series of the targeted properties. This quality control includes data gathering from different instruments and check for internal consistency and disregard of invalid data. Chambers characteristics, experimental protocol and metadata are attached. These data are produced by NF and are made available in the DASCS.

* Level 2.5: Approved and fully quality controlled time series of the targeted properties after corrections for wall losses and dilution have been applied. Chambers characteristics, experimental protocol and
metadata are attached. These data are produced by NF after level 2 data processing and are made available in the DASCS.

* **Level 3:** Approved and fully quality controlled advanced data products (rate constants, cross sections, SOA yields, complex refractive index of aerosols ...). These data are produced by NF after level 2.5 data processing and are made available in the LAR and in the LADP.

The complete data workflow for these data levels is depicted as diagram in Annex 7. It should be noticed that unlike other data centre units, all the data processing is performed by NFs while the data centre unit is in charge of data curation for Level 2 to Level 3 data as well as tools and services for data providers and data users. The detailed list of ACTRIS measurement variables as well as level 3 data products provided by the ACTRIS Exploratory Platforms, i.e. by simulation chambers, has not been fully established so far and will be provided in a second step.

### 3.1.5.2 Data curation services for ACTRIS atmospheric simulation chamber data

Curation of Level 2 to Level 3 data is ensured by ACTRIS DC. The data curation service need to bring together all the processes that applied to datasets from the moment they enter the data centre. The important steps in the curation of atmospheric chamber data are as follows:

* **Identification:** When entering the data centre, each dataset is assigned a unique identifier (uuid). This identifier is usually a 16 character long meaningless code. It need to follow it in all curation processes.

* **Cataloguing:** Each dataset is associated with a metadata record that provides the usual information (abstract, title, contact, etc.) This catalogue implements a certain number of standards: it can be requested via the CSW protocol and its content is compliant to ISO 19115 standards.

* **Version control:** The different versions of the same dataset are kept in the data centre. Submitting a new version involves providing a description and a motivation of the changes performed. All of these elements are kept in the metadata file to provide a precise history of the data.

* **Backup and Archiving:** A daily backup mechanism is put in place. This mechanism allows performing a quick data recovery in case of human error in the handling of data files. In addition, a more complex archiving mechanism based on the use of multiple remote sites and regular integrity checking processes is also set up. It ensures that the contents of the files in the data centre do not change because of storage media issues.

* **Quality control:** The quality of data centre data sets is ensured by the establishment of a repository portal. An automatic tool checks for the quality of the metadata (mandatory fields, controlled vocabulary). The use of shared formats by the community (EDF, JDX ...) ensures the homogeneity of the data. In addition, verification scripts are used at the time of filing. Finally, the data centre provides the NF with validated libraries that make it easy to produce the requested formats.

### 3.1.5.3 Tools and services provided for simulation chamber data production and usage

Services are a set of value-added processes for both the data provider and the data user. The main services for atmospheric chamber data are as follows:

* Online portal for standardized submission of data by the NF,

* Standardized sanity and consistency checks of data on submission,
metadata are attached. These data are produced by NF after level 2 data processing and are made available in the DASCS.

* **Level 3:** Approved and fully quality controlled advanced data products (rate constants, cross sections, SOA yields, complex refractive index of aerosols ...). These data are produced by NF after level 2.5 data processing and are made available in the LAR and in the LADP.

The complete data workflow for these data levels is depicted as diagram in Annex 7. It should be noticed that unlike other data centre units, all the data processing is performed by NFs while the data centre unit is in charge of data curation for Level 2 to Level 3 data as well as tools and services for data providers and data users. The detailed list of ACTRIS measurement variables as well as level 3 data products provided by the ACTRIS Exploratory Platforms, i.e. by simulation chambers, has not been fully established so far and will be provided in a second step.

### 3.1.5.2 Data curation services for ACTRIS atmospheric simulation chamber data

Curation of Level 2 to Level 3 data is ensured by ACTRIS DC. The data curation service need to bring together all the processes that applied to datasets from the moment they enter the data centre. The important steps in the curation of atmospheric chamber data are as follows:

* **Identification:** When entering the data centre, each dataset is assigned a unique identifier (uuid). This identifier is usually a 16 character long meaningless code. It need to follow it in all curation processes.

* **Cataloguing:** Each dataset is associated with a metadata record that provides the usual information (abstract, title, contact, etc.) This catalogue implements a certain number of standards: it can be requested via the CSW protocol and its content is compliant to ISO 19115 standards.

* **Version control:** The different versions of the same dataset are kept in the data centre. Submitting a new version involves providing a description and a motivation of the changes performed. All of these elements are kept in the metadata file to provide a precise history of the data.

* **Backup and Archiving:** A daily backup mechanism is put in place. This mechanism allows performing a quick data recovery in case of human error in the handling of data files. In addition, a more complex archiving mechanism based on the use of multiple remote sites and regular integrity checking processes is also set up. It ensures that the contents of the files in the data centre do not change because of storage media issues.

* **Quality control:** The quality of data centre data sets is ensured by the establishment of a repository portal. An automatic tool checks for the quality of the metadata (mandatory fields, controlled vocabulary). The use of shared formats by the community (EDF, JDX ...) ensures the homogeneity of the data. In addition, verification scripts are used at the time of filing. Finally, the data centre provides the NF with validated libraries that make it easy to produce the requested formats.

### 3.1.5.3 Tools and services provided for simulation chamber data production and usage

Services are a set of value-added processes for both the data provider and the data user. The main services for atmospheric chamber data are as follows:

* Online portal for standardized submission of data by the NF,

* Standardized sanity and consistency checks of data on submission,
* **Data Object Identifier (DOI):** A DOI is automatically associated with each dataset to facilitate its quotation in an article. For this, its suffix must be a short and insignificant chain. So it is not the uuid, but the data centre keeps the correspondence between these two values up to date. The landing page of this DOI is the metadata record describing the dataset. All DOI metadata provided to DataCite comes from the metadata record.

* **Data preview:** In order to allow the user a better data discovery, data preview mechanisms are set up.

* **Data access:** The different datasets are downloadable in their different versions.

* **Usage Report:** A report is regularly sent to the data producers. This report describes the number and origin of downloads of the different datasets that the producer has deposited in the data centre.

* **Change alert:** A user can sign up to be notified of different changes in a dataset.

## 3.2 Estimation of the need

The table shows the estimated number of annual data sets from the NFs, and the associated need for data storage for the various types of data.

<table><thead><tr><th rowspan="3"></th><th colspan="3">Number of annual data sets</th><th colspan="3">Data volume</th></tr><tr><th rowspan="2">Now</th><th colspan="2">by 2025</th><th rowspan="2">Now</th><th colspan="2">by 2025</th></tr><tr><th>Min.</th><th>Max.</th><th>Min.</th><th>Max.</th></tr></thead><tbody><tr><td>ACTRIS in situ aerosol data</td><td>60</td><td>50</td><td>120</td><td>18 000 MB</td><td>15 000 MB</td><td>50 000 MB</td></tr><tr><td>ACTRIS in situ cloud data</td><td>0</td><td>35</td><td>105</td><td>0</td><td>1 GB</td><td>3 GB</td></tr><tr><td>ACTRIS in situ trace gas data</td><td>27</td><td>30</td><td>60</td><td>300 MB</td><td>200 MB</td><td>400 MB</td></tr><tr><td>ACTRIS aerosol remote sensing data</td><td>28</td><td>30</td><td>70</td><td>4 GB</td><td>2.5 TB</td><td>25 TB</td></tr><tr><td>ACTRIS cloud remote sensing data</td><td>9</td><td>9</td><td>15</td><td>5 TB</td><td>15 TB</td><td>30 TB</td></tr><tr><td>ACTRIS trace gas remote sensing data</td><td>57</td><td>60</td><td>80</td><td>400 MB</td><td>400 MB</td><td>550 MB</td></tr><tr><td>ACTRIS Atmospheric simulation chamber data</td><td>160</td><td>150</td><td>250</td><td>1 GB</td><td>3 GB</td><td>10 GB</td></tr></tbody></table>
* **Data Object Identifier (DOI):** A DOI is automatically associated with each dataset to facilitate its quotation in an article. For this, its suffix must be a short and insignificant chain. So it is not the uuid, but the data centre keeps the correspondence between these two values up to date. The landing page of this DOI is the metadata record describing the dataset. All DOI metadata provided to DataCite comes from the metadata record.

* **Data preview:** In order to allow the user a better data discovery, data preview mechanisms are set up.

* **Data access:** The different datasets are downloadable in their different versions.

* **Usage Report:** A report is regularly sent to the data producers. This report describes the number and origin of downloads of the different datasets that the producer has deposited in the data centre.

* **Change alert:** A user can sign up to be notified of different changes in a dataset.

## 3.2 Estimation of the need

The table shows the estimated number of annual data sets from the NFs, and the associated need for data storage for the various types of data.

<table><thead><tr><th rowspan="3"></th><th colspan="3">Number of annual data sets</th><th colspan="3">Data volume</th></tr><tr><th rowspan="2">Now</th><th colspan="2">by 2025</th><th rowspan="2">Now</th><th colspan="2">by 2025</th></tr><tr><th>Min.</th><th>Max.</th><th>Min.</th><th>Max.</th></tr></thead><tbody><tr><td>ACTRIS in situ aerosol data</td><td>60</td><td>50</td><td>120</td><td>18 000 MB</td><td>15 000 MB</td><td>50 000 MB</td></tr><tr><td>ACTRIS in situ cloud data</td><td>0</td><td>35</td><td>105</td><td>0</td><td>1 GB</td><td>3 GB</td></tr><tr><td>ACTRIS in situ trace gas data</td><td>27</td><td>30</td><td>60</td><td>300 MB</td><td>200 MB</td><td>400 MB</td></tr><tr><td>ACTRIS aerosol remote sensing data</td><td>28</td><td>30</td><td>70</td><td>4 GB</td><td>2.5 TB</td><td>25 TB</td></tr><tr><td>ACTRIS cloud remote sensing data</td><td>9</td><td>9</td><td>15</td><td>5 TB</td><td>15 TB</td><td>30 TB</td></tr><tr><td>ACTRIS trace gas remote sensing data</td><td>57</td><td>60</td><td>80</td><td>400 MB</td><td>400 MB</td><td>550 MB</td></tr><tr><td>ACTRIS Atmospheric simulation chamber data</td><td>160</td><td>150</td><td>250</td><td>1 GB</td><td>3 GB</td><td>10 GB</td></tr></tbody></table>
## 3.3 ACTRIS Data provenance, attribution, and traceability

The term “provenance” has originally been used in the context of archiving historical objects, where it describes the documentation of the production process if known, the history of ownership and the places and conditions of storage.

In data science, “provenance” is used for the process of documenting individual executions of a workflow to the point that each step can be reproduced. Thus, provenance is the tool for establishing traceability. Documenting provenance has at least 3 important applications:

1) Attributing the contributions to the workflow to the entities involved in the workflow

2) Making the workflow product traceable

3) Tracing errors in the workflow and removing them by re-executing the workflow.

To document provenance in a workflow, each component used in the workflow need to be uniquely identified by persistent identifiers (PIDs). This applies to:

* Humans, e.g. identified by their ORCID.

* Legal entities. Candidate identifier systems for legal entities such as funding agencies and affiliations are the International Standard Name Identifier (ISNI), the Ringgold system, and OrgIDs.

* Final data products, identified by their Digital Object Identifier (DOI).

* Algorithms, software, instruments, data and instrument quality assurance and quality control reports, and data pre-products, identified by a general PID. Candidate PID systems include the Handle System, Persistent URLs (PURLs), and the European persistent identifier consortium (ePIC) system.

All algorithms, software, data and instrument quality assurance and quality control reports, and data pre- and final products used or produced anywhere in ACTRIS data production workflows will be archived in suitable repositories. These repositories must be accessible by referencing their PIDs, and meet the need for long-term archive standards. For keeping the PID references unique, these repositories must have version control.

It is required that all data pre-products, algorithms, software, legal entities, instruments, and relevant data and instrument quality management documents used in the production of a data pre- or final product is referenced in the metadata by their PIDs. This is achieved by means of a data provenance framework. In this respect, ACTRIS shall use the recommendations and experience gained in ENVRI. A provenance framework describes the elements in a workflow as resources such as “artefacts” (immutable pieces of state), processes, and entities controlling these processes. These are put into relations such as “used” (a process used some artefact), “wasControlledBy” (an agent controlled some process), “wasGeneratedBy” (a process generated an artefact), “wasDerivedFrom” (an artefact was derived from another artefact) and “wasTriggeredBy” (a process was triggered by another process). Potential relevant data provenance frameworks include:

* The Open Provenance Model (OPM)

* The PROV model
## 3.3 ACTRIS Data provenance, attribution, and traceability

The term “provenance” has originally been used in the context of archiving historical objects, where it describes the documentation of the production process if known, the history of ownership and the places and conditions of storage.

In data science, “provenance” is used for the process of documenting individual executions of a workflow to the point that each step can be reproduced. Thus, provenance is the tool for establishing traceability. Documenting provenance has at least 3 important applications:

1) Attributing the contributions to the workflow to the entities involved in the workflow

2) Making the workflow product traceable

3) Tracing errors in the workflow and removing them by re-executing the workflow.

To document provenance in a workflow, each component used in the workflow need to be uniquely identified by persistent identifiers (PIDs). This applies to:

* Humans, e.g. identified by their ORCID.

* Legal entities. Candidate identifier systems for legal entities such as funding agencies and affiliations are the International Standard Name Identifier (ISNI), the Ringgold system, and OrgIDs.

* Final data products, identified by their Digital Object Identifier (DOI).

* Algorithms, software, instruments, data and instrument quality assurance and quality control reports, and data pre-products, identified by a general PID. Candidate PID systems include the Handle System, Persistent URLs (PURLs), and the European persistent identifier consortium (ePIC) system.

All algorithms, software, data and instrument quality assurance and quality control reports, and data pre- and final products used or produced anywhere in ACTRIS data production workflows will be archived in suitable repositories. These repositories must be accessible by referencing their PIDs, and meet the need for long-term archive standards. For keeping the PID references unique, these repositories must have version control.

It is required that all data pre-products, algorithms, software, legal entities, instruments, and relevant data and instrument quality management documents used in the production of a data pre- or final product is referenced in the metadata by their PIDs. This is achieved by means of a data provenance framework. In this respect, ACTRIS shall use the recommendations and experience gained in ENVRI. A provenance framework describes the elements in a workflow as resources such as “artefacts” (immutable pieces of state), processes, and entities controlling these processes. These are put into relations such as “used” (a process used some artefact), “wasControlledBy” (an agent controlled some process), “wasGeneratedBy” (a process generated an artefact), “wasDerivedFrom” (an artefact was derived from another artefact) and “wasTriggeredBy” (a process was triggered by another process). Potential relevant data provenance frameworks include:

* The Open Provenance Model (OPM)

* The PROV model
Each potential ACTRIS DC node needs to select and implements provenance documentation by annotating each connection in its data production workflow with the respective relation defined in the provenance framework.

## 3.4 Operation support for knowledge transfer and training

### 3.4.1 Training of instrument operators and data submitters

ACRTIS DC must offer training of data producers and scientists at ACTRIS NFs for:

* Experienced data producers and scientists facing a potential upgrade of their instrument, exchange on instrument methodologies or extension of the NF with more and additional instruments recommended within ACTRIS

* New operators that need to learn and comply with the protocols and procedures valid for reporting of ACTRIS data

* Availability of new SOPs, QA procedures and tools, and/or data evaluation procedures and plausibility tests

* New types or QC tools and versions available, or revised versions of existing QC tools

The training shall be organized on various channels:

* The data centre shall offer opportunities for focused training sessions on pre-defined data types ((e.g. remote sensing/in situ) and topics (e.g. RRT/QA data, reporting procedures and tools, meta data, flagging, application of QC tools etc.)

* Transfer of expertise during online exercises and workshops

* Documentation, procedures, tutorials and tools available on the data centre website for e.g. data QC and submission,

* Guidance for NFs in setting up data flows to DC unit

* Help desk for data submission and reporting periods

* Data centre participation on summer/winter school for students and scientists and during large comprehensive campaigns

### 3.4.2 Consultancy for setting-up new data flow from new sites or new instrument at existing sites

New measurement techniques, technological products and methods are developed by the TC in collaboration with the NFs. Depending on the situation, ACTRIS DC may recommend to the ACTRIS RI Committee to decide on the implementation of such new techniques at the RI level. The data centre needs to offer assistants to the NF in setting up data stream from new measurement techniques, if this is embraced by ACTRIS RI Committee and need to be implemented as part of the National Facilities and the ACTRIS labels.

## 3.5 Access to documentation for ACTRIS standards and data flow

Documentation generated in ACTRIS data curation procedures includes quality management concepts and reports, data management concepts and workflows, operating procedures, quality control reports and others. Many of these documents are referenced in the metadata of the various data products. It is required that all documents and reports are stored in a
Each potential ACTRIS DC node needs to select and implements provenance documentation by annotating each connection in its data production workflow with the respective relation defined in the provenance framework.

## 3.4 Operation support for knowledge transfer and training

### 3.4.1 Training of instrument operators and data submitters

ACRTIS DC must offer training of data producers and scientists at ACTRIS NFs for:

* Experienced data producers and scientists facing a potential upgrade of their instrument, exchange on instrument methodologies or extension of the NF with more and additional instruments recommended within ACTRIS

* New operators that need to learn and comply with the protocols and procedures valid for reporting of ACTRIS data

* Availability of new SOPs, QA procedures and tools, and/or data evaluation procedures and plausibility tests

* New types or QC tools and versions available, or revised versions of existing QC tools

The training shall be organized on various channels:

* The data centre shall offer opportunities for focused training sessions on pre-defined data types ((e.g. remote sensing/in situ) and topics (e.g. RRT/QA data, reporting procedures and tools, meta data, flagging, application of QC tools etc.)

* Transfer of expertise during online exercises and workshops

* Documentation, procedures, tutorials and tools available on the data centre website for e.g. data QC and submission,

* Guidance for NFs in setting up data flows to DC unit

* Help desk for data submission and reporting periods

* Data centre participation on summer/winter school for students and scientists and during large comprehensive campaigns

### 3.4.2 Consultancy for setting-up new data flow from new sites or new instrument at existing sites

New measurement techniques, technological products and methods are developed by the TC in collaboration with the NFs. Depending on the situation, ACTRIS DC may recommend to the ACTRIS RI Committee to decide on the implementation of such new techniques at the RI level. The data centre needs to offer assistants to the NF in setting up data stream from new measurement techniques, if this is embraced by ACTRIS RI Committee and need to be implemented as part of the National Facilities and the ACTRIS labels.

## 3.5 Access to documentation for ACTRIS standards and data flow

Documentation generated in ACTRIS data curation procedures includes quality management concepts and reports, data management concepts and workflows, operating procedures, quality control reports and others. Many of these documents are referenced in the metadata of the various data products. It is required that all documents and reports are stored in a
versioned document repository for long-term archiving, and identified by a PID (persistent identifier). Documents are distinguished between open access and RI internal, where access conditions to the open access documents are defined in the access policy. As a general rule, at least all documents referenced in the metadata of the data product need to have open access.

Open access documents and internal documents include:

* Standard operating procedures

* Data quality control reports

* Instrument quality control reports

* Data and instrument quality assurance concepts

* NF, CF, and DC concept documents

* Workflow implementations plans

## 4 Services provided to ACTRIS users

An ACTRIS user is a person, a team, or an institution using either ACTRIS data or any other ACTRIS service. ACTRIS users originate from academia, business, industry and public services, from ACTRIS member countries and from countries which are not ACTRIS members, both inside and outside Europe.

As a tool for science, the highest priority for the ACTRIS Data Centre is to maintain and increase the availability of ACTRIS data and data products relevant to climate and air quality research for all interested users. National and international climate and air quality assessments are employing ACTRIS data, and are the ultimate user of ACTRIS data and data products. Level 3 data offering ACTRIS data with other available data is highly valuable for a wide community. Most of the level 3 data products developed in the framework of ACTRIS shall be derived from a combination of multi-source and/or multi-temporal parameters and variables: synergetic retrieval from different instruments, combination of ground-based data, and satellite and model data. They can also be derived from an advanced processing of data obtained from simulation chamber experiments. Annex II lists the level 3 data. This section includes a brief description of each of the products planned, sorted the subcategories. The ACTRIS Data Centre aims to put in place and offer to all users the specific level 3 products marked with * in this document, from year 1. The rest can be implemented later, depending on support and expressed user needs.
versioned document repository for long-term archiving, and identified by a PID (persistent identifier). Documents are distinguished between open access and RI internal, where access conditions to the open access documents are defined in the access policy. As a general rule, at least all documents referenced in the metadata of the data product need to have open access.

Open access documents and internal documents include:

* Standard operating procedures

* Data quality control reports

* Instrument quality control reports

* Data and instrument quality assurance concepts

* NF, CF, and DC concept documents

* Workflow implementations plans

## 4 Services provided to ACTRIS users

An ACTRIS user is a person, a team, or an institution using either ACTRIS data or any other ACTRIS service. ACTRIS users originate from academia, business, industry and public services, from ACTRIS member countries and from countries which are not ACTRIS members, both inside and outside Europe.

As a tool for science, the highest priority for the ACTRIS Data Centre is to maintain and increase the availability of ACTRIS data and data products relevant to climate and air quality research for all interested users. National and international climate and air quality assessments are employing ACTRIS data, and are the ultimate user of ACTRIS data and data products. Level 3 data offering ACTRIS data with other available data is highly valuable for a wide community. Most of the level 3 data products developed in the framework of ACTRIS shall be derived from a combination of multi-source and/or multi-temporal parameters and variables: synergetic retrieval from different instruments, combination of ground-based data, and satellite and model data. They can also be derived from an advanced processing of data obtained from simulation chamber experiments. Annex II lists the level 3 data. This section includes a brief description of each of the products planned, sorted the subcategories. The ACTRIS Data Centre aim to put in place and offer to all users the specific level 3 products marked with * in this document, from year 1. The rest can be implemented later, depending on support and expressed user needs.
## 4.1 Estimation of the need

<table><thead><tr><th rowspan="3">Type of ACTRIS user</th><th colspan="3">Number of users to which ACTRIS DC is providing services per year</th></tr><tr><th rowspan="2">Now</th><th colspan="2">by 2025</th></tr><tr><th>Min.</th><th>Max.</th></tr></thead><tbody><tr><td>Academia, Business, Industry, Public services</td><td>600</td><td>400</td><td>4000</td></tr></tbody></table>

Based on current statistics, academic users are likely to be more than 80%, and governmental and intergovernmental bodies constitute around 3-5 %.

## 4.2 Access to ACTRIS data and digital tools

ACTRIS DC shall offer access to data, data products and digital tools through a single entry point, the ACTRIS data user interface. As a tool for science, the highest priority for the ACTRIS Data Centre will be to provide access to ACTRIS data and data products relevant to climate and air quality research for all interested users. Access to some ACTRIS services is open and free, most importantly the access to ACTRIS data, data products, and digital tools provided by the DC. Other access to ACTRIS services is considered competitive access based on capacity or excellence and require a review process that will be centrally managed by the HO/SAMU. SAMU is the single point of entry for user access to all TC services and to some specific services and data products provided by the DC. Access is regulated by both the ACTRIS access policy and the ACTRIS data policy, respectively.

### 4.2.1 Access to ACTRIS level 0

It is required that access to level 0 data need to be upon specific requests and regulated by a license, depending on the variables and tailored to the various types of data. Level 0 data encompass huge data volumes, and shall be archived in accordance with the requirements related to this. This ensures full traceability of ACTRIS data, in a flexible system meeting the specific needs for the various data types.

### 4.2.2 Access to ACTRIS level 1

It is required that access to level 1 data can be regulated by variable, but is restricted by default. Level 1 data do not need to be accessible directly through the ACTRIS data user interface, with the exception of RRT and RRT data products. All level 1 data shall be discoverable and accessible by the machine-to-machine interfaces according to their access policy. The level 1 data access policy for each ACTRIS variable is specified in Annex I. For restricted level 1 data, ACTRIS will offer common license models, taking into account that there may be different needs for RRT/NRT data, which are specified in the data policy.

### 4.2.3 Access to ACTRIS level 2

It is required that access to all ACTRIS level 2 data shall be open, free and offered through the ACTRIS data user interface. The access shall follow the FAIR principles (see section 3.3).
## 4.1 Estimation of the need

<table><thead><tr><th rowspan="3">Type of ACTRIS user</th><th colspan="3">Number of users to which ACTRIS DC is providing services per year</th></tr><tr><th rowspan="2">Now</th><th colspan="2">by 2025</th></tr><tr><th>Min.</th><th>Max.</th></tr></thead><tbody><tr><td>Academia, Business, Industry, Public services</td><td>600</td><td>400</td><td>4000</td></tr></tbody></table>

Based on current statistics, academic users are likely to be more than 80%, and governmental and intergovernmental bodies constitute around 3-5 %.

## 4.2 Access to ACTRIS data and digital tools

ACTRIS DC shall offer access to data, data products and digital tools through a single entry point, the ACTRIS data user interface. As a tool for science, the highest priority for the ACTRIS Data Centre will be to provide access to ACTRIS data and data products relevant to climate and air quality research for all interested users. Access to some ACTRIS services is open and free, most importantly the access to ACTRIS data, data products, and digital tools provided by the DC. Other access to ACTRIS services is considered competitive access based on capacity or excellence and require a review process that will be centrally managed by the HO/SAMU. SAMU is the single point of entry for user access to all TC services and to some specific services and data products provided by the DC. Access is regulated by both the ACTRIS access policy and the ACTRIS data policy, respectively.

### 4.2.1 Access to ACTRIS level 0

It is required that access to level 0 data need to be upon specific requests and regulated by a license, depending on the variables and tailored to the various types of data. Level 0 data encompass huge data volumes, and shall be archived in accordance with the requirements related to this. This ensures full traceability of ACTRIS data, in a flexible system meeting the specific needs for the various data types.

### 4.2.2 Access to ACTRIS level 1

It is required that access to level 1 data can be regulated by variable, but is restricted by default. Level 1 data do not need to be accessible directly through the ACTRIS data user interface, with the exception of RRT and RRT data products. All level 1 data shall be discoverable and accessible by the machine-to-machine interfaces according to their access policy. The level 1 data access policy for each ACTRIS variable is specified in Annex I. For restricted level 1 data, ACTRIS will offer common license models, taking into account that there may be different needs for RRT/NRT data, which are specified in the data policy.

### 4.2.3 Access to ACTRIS level 2

It is required that access to all ACTRIS level 2 data shall be open, free and offered through the ACTRIS data user interface. The access shall follow the FAIR principles (see section 3.3).
4.2.4 Access to ACTRIS level 3 and to specific data products on demand

It is required that access to standard ACTRIS level 3 data shall be open, free and offered through the ACTRIS data user interface. The access shall follow the FAIR principles (see section 3.3).

It is also required that ACTRIS offer access to specific tailboard data products and tools on demand. This is considered as competitive access and can be based on capacity or excellence. SAMU is the single point of entry for user access to all TC services and to some specific services and data products provided by the DC. This will require a review process that is centrally managed by the HO/SAMU.

4.2.5 Access to digital tools

It is required that the ACTRIS data user interface offers access to digital tools for data production, quality control and analysis. Access to selected tools can be regulated, depending on the application, and SAMU will organise and manage the access. ACTRIS will also offer a common license for digital tools.

4.3 Production of level 3 data solely based on ACTRIS observations from NF

4.3.1 Aerosol surface in situ data – combination of variables and instruments

ACTRIS DC shall produce different products resulting from the processing at DC itself of atmospheric aerosol variables measured in situ at ACTRIS NFs. ACTRIS DC will offer several products resulting from combining data provided by different in situ instruments. The use cases comprise QC at NFs by means of closure (comparison of same variable obtained by different measurements or retrievals), and verification of climate and air quality model results. The targeted aerosol variables comprise physical (full-range particle number size distribution, PM mass concentrations derived from particle size distribution) and optical ones (extinction and scattering coefficients, single scattering albedo, all dry-state), as well as data compilations.

4.3.2 Aerosol remote sensing data – combination of variables and instruments

ACTRIS DC shall produce different products resulting from the processing at DC itself of Level 2 LIDAR and photometer data collected at the aerosol remote sensing NFs. Such products include profiles of aerosol volume concentration, potentially of great interest for modellers, and local, national and international authorities.

4.3.3 Data products from simulation chamber experiments

ACTRIS DC shall provide level 3 data products derived from simulation chamber experiments. These advanced data products are used for researchers working on atmospheric observations as well as atmospheric model development and validation. They include products for the development of chemical mechanisms in atmospheric models, products for the retrieval of satellite and for radiative transfer modelling, e.g. rate constants for gas and condensed phase reactions, mass extinction coefficients of aerosols, absorption cross sections and Secondary Organic Aerosol yields.
4.2.4 Access to ACTRIS level 3 and to specific data products on demand

It is required that access to standard ACTRIS level 3 data shall be open, free and offered through the ACTRIS data user interface. The access shall follow the FAIR principles (see section 3.3).

It is also required that ACTRIS offer access to specific tailboard data products and tools on demand. This is considered as competitive access and can be based on capacity or excellence. SAMU is the single point of entry for user access to all TC services and to some specific services and data products provided by the DC. This will require a review process that is centrally managed by the HO/SAMU.

4.2.5 Access to digital tools

It is required that the ACTRIS data user interface offers access to digital tools for data production, quality control and analysis. Access to selected tools can be regulated, depending on the application, and SAMU will organise and manage the access. ACTRIS will also offer a common license for digital tools.

4.3 Production of level 3 data solely based on ACTRIS observations from NF

4.3.1 Aerosol surface in situ data – combination of variables and instruments

ACTRIS DC shall produce different products resulting from the processing at DC itself of atmospheric aerosol variables measured in situ at ACTRIS NFs. ACTRIS DC will offer several products resulting from combining data provided by different in situ instruments. The use cases comprise QC at NFs by means of closure (comparison of same variable obtained by different measurements or retrievals), and verification of climate and air quality model results. The targeted aerosol variables comprise physical (full-range particle number size distribution, PM mass concentrations derived from particle size distribution) and optical ones (extinction and scattering coefficients, single scattering albedo, all dry-state), as well as data compilations.

4.3.2 Aerosol remote sensing data – combination of variables and instruments

ACTRIS DC shall produce different products resulting from the processing at DC itself of Level 2 LIDAR and photometer data collected at the aerosol remote sensing NFs. Such products include profiles of aerosol volume concentration, potentially of great interest for modellers, and local, national and international authorities.

4.3.3 Data products from simulation chamber experiments

ACTRIS DC shall provide level 3 data products derived from simulation chamber experiments. These advanced data products are used for researchers working on atmospheric observations as well as atmospheric model development and validation. They include products for the development of chemical mechanisms in atmospheric models, products for the retrieval of satellite and for radiative transfer modelling, e.g. rate constants for gas and condensed phase reactions, mass extinction coefficients of aerosols, absorption cross sections and Secondary Organic Aerosol yields.
These data are produced by exploratory NF after level 2.5 data processing. ACTRIS DC offers data curation service and long term archive. It can also provide tools for data visualisation and treatment. Level 3 data from exploratory platforms are not shown in annex II.

### 4.3.4 ReOBS - long-term (> 10 years) multi-parameter product

ACTRIS DC shall produce long-term (> 10 years) multi-parameter, homogenized and harmonized datasets following the ReOBS approach for all variables available in annex I. ReOBS refers to a scientific approach that aims to aggregate and harmonize all geophysical variables available at a given ACTRIS NF on a regular temporal scale (typically hourly) over a long time period (decadal and beyond). ReOBS long term data are Re-calibrated, Re-quality controlled, Re-expertized, Re-averaged, Re-formatted, and Re-nomenclatured. The resulting harmonized dataset is a unique resource to support multiannual and multi-variables studies combining atmospheric dynamics and thermodynamics, radiation, clouds, aerosols, and reactive trace gases from ground-based observations.

While individual datasets from ACTRIS NF observations exist, the application of synergy between different types of observations is currently under-used because of complexity in the exploitation of multi-variable datasets and diversity inherent to calibration, quality control, treatment, format, temporal averaging, and metadata. The use of synergy shall be as users will have access to ReOBS datasets.

The ReOBS approach must be tightly connected to other tools and services offered by the DC. For example, the ReOBS approach will utilize gap filling tools (see section 4.5.4). ReOBS datasets enhance the capacity of the DC to provide model evaluation services, and shall serve these users. Pilot products will be available from year 1, the number of NFs will gradually increase.

### 4.3.5 Climatology products for ACTRIS variables @National Facilities across Europe

ACTRIS DC shall produce climatology products updated yearly suitable for both the scientific community and authorities and policy makers. These include monthly and seasonal means of selected ACTRIS variables based on the compiled level 2 observations of aerosol in situ, aerosol profiles, trace gas in situ data. The products will utilize the data production tools described in section 4.5.2. See annex II for more details.

### 4.3.6 Source apportionment of submicron organic aerosols in Europe

ACTRIS DC shall offer products including long-term trends and seasonal variation of the most important organic aerosols (OA) source signatures in Europe. A source apportionment tool (e.g., based on Multilinear Engine (ME2)) can be used for a factorial analysis of level 2 datasets. This approach identifies organic factor profiles and their resulting long-term trends. The TC for aerosol in situ measurements has to make available the necessary products including metadata.

### 4.3.7 Volatile Organic Compounds (VOC) source attribution in Europe

ACTRIS DC shall offer products including long-term trends and seasonal variation of the most important VOC source signatures in Europe using a receptor oriented approach. A source apportionment tool (e.g. Positive Matrix Factorization-PMF) can be used for factorial analysis of level 2 datasets for selected of
These data are produced by exploratory NF after level 2.5 data processing. ACTRIS DC offers data curation service and long term archive. It can also provide tools for data visualisation and treatment. Level 3 data from exploratory platforms are not shown in annex II.

### 4.3.4 ReOBS - long-term (> 10 years) multi-parameter product

ACTRIS DC shall produce long-term (> 10 years) multi-parameter, homogenized and harmonized datasets following the ReOBS approach for all variables available in annex I. ReOBS refers to a scientific approach that aims to aggregate and harmonize all geophysical variables available at a given ACTRIS NF on a regular temporal scale (typically hourly) over a long time period (decadal and beyond). ReOBS long term data are Re-calibrated, Re-quality controlled, Re-expertized, Re-averaged, Re-formatted, and Re-nomenclatured. The resulting harmonized dataset is a unique resource to support multiannual and multi-variables studies combining atmospheric dynamics and thermodynamics, radiation, clouds, aerosols, and reactive trace gases from ground-based observations.

While individual datasets from ACTRIS NF observations exist, the application of synergy between different types of observations is currently under-used because of complexity in the exploitation of multi-variable datasets and diversity inherent to calibration, quality control, treatment, format, temporal averaging, and metadata. The use of synergy shall be as users will have access to ReOBS datasets.

The ReOBS approach must be tightly connected to other tools and services offered by the DC. For example, the ReOBS approach will utilize gap filling tools (see section 4.5.4). ReOBS datasets enhance the capacity of the DC to provide model evaluation services, and shall serve these users. Pilot products will be available from year 1, the number of NFs will gradually increase.

### 4.3.5 Climatology products for ACTRIS variables @National Facilities across Europe

ACTRIS DC shall produce climatology products updated yearly suitable for both the scientific community and authorities and policy makers. These include monthly and seasonal means of selected ACTRIS variables based on the compiled level 2 observations of aerosol in situ, aerosol profiles, trace gas in situ data. The products will utilize the data production tools described in section 4.5.2. See annex II for more details.

### 4.3.6 Source apportionment of submicron organic aerosols in Europe

ACTRIS DC shall offer products including long-term trends and seasonal variation of the most important organic aerosols (OA) source signatures in Europe. A source apportionment tool (e.g., based on Multilinear Engine (ME2)) can be used for a factorial analysis of level 2 datasets. This approach identifies organic factor profiles and their resulting long-term trends. The TC for aerosol in situ measurements has to make available the necessary products including metadata.

### 4.3.7 Volatile Organic Compounds (VOC) source attribution in Europe

ACTRIS DC shall offer products including long-term trends and seasonal variation of the most important VOC source signatures in Europe using a receptor oriented approach. A source apportionment tool (e.g. Positive Matrix Factorization-PMF) can be used for factorial analysis of level 2 datasets for selected of
variables resulting in two output datasets describing the chemical profiles of the factor and a time series
of the factor contribution. Products must be updated regularly, e.g. Yearly updated.

4.3.8 Cloud occurrence @ cloud in situ National Facilities

The ACTRIS DC will produce monthly updates of cloud occurrence at ACTRIS observational platforms with cloud in situ instrumentation. The analysis will be based on level 2 data of the cloud liquid water content and will include both highly time resolved data series of cloud free and cloudy conditions as well as monthly and yearly statistics of cloud coverage at the stations. These products will be needed for the interpretation of other in situ measurements at the same stations and may also be used to constrain and further improve cloud, weather and climate models. Long-term series of cloud occurrence at several stations in Europe will also contribute to identify trends in regional weather and climate systems.

4.4 Production of ACTRIS level 3 data and tools through multi-source data integration services, employing external ground based measurement data

4.4.1 Bridge to external ground-based observational data relevant for ACTRIS

ACTRIS DC shall provide access to external data holdings and repositories of ground-based observations commonly used by ACTRIS users, valuable when combined with ACTRIS data. This functionality shall facilitate contextual analysis, inter-comparison, and validation purposes, and is required to produce derived products using multi-instrument synergetic retrieval algorithms. These regional and global networks and initiatives include EMEP, GAW, AERONET and NDACC.

4.4.2 Collocation service of data from regional and global networks

ACTRIS DC shall offer comprehensive data products combining ACTRIS data with data from regional and global networks, based on the functionality described in section 4.4.1. ACTRIS DC will offer yearly updates of benchmark data products adding complementary data from GAW and EMEP together with ACTRIS data e.g. ACTRIS variables presented together with PM and/or sulphate at the ACTRIS National Facilities. This will also provide data sets with global coverage, employing ACTRIS methods on data from sites outside Europe. The selection of variables can be made upon user requests, regulated through review process controlled by SAMU. See annex II for more details.

4.4.3 Aerosol remote sensing data – combination of variables and instruments from global networks

ACTRIS DC shall provide level 3 products derived from the standard AERONET products. Based on NASA algorithms, including AERONET Level 1 (Synergy or Single) data: Spectral refractive indexes, spectral extinction/absorption AOD, single scattering albedo, spectral LIDAR ratio, Ångström exponent, volume size distribution and spherical fraction. Furthermore, ACTRIS DC shall offer Direct Sun/Moon Extinction Aerosol Optical Depth (column) from AERONET, and Column Water Vapour Content.
variables resulting in two output datasets describing the chemical profiles of the factor and a time series
of the factor contribution. Products must be updated regularly, e.g. Yearly updated.

4.3.8 Cloud occurrence @ cloud in situ National Facilities

The ACTRIS DC will produce monthly updates of cloud occurrence at ACTRIS observational platforms with cloud in situ instrumentation. The analysis will be based on level 2 data of the cloud liquid water content and will include both highly time resolved data series of cloud free and cloudy conditions as well as monthly and yearly statistics of cloud coverage at the stations. These products will be needed for the interpretation of other in situ measurements at the same stations and may also be used to constrain and further improve cloud, weather and climate models. Long-term series of cloud occurrence at several stations in Europe will also contribute to identify trends in regional weather and climate systems.

4.4 Production of ACTRIS level 3 data and tools through multi-source data integration services, employing external ground based measurement data

4.4.1 Bridge to external ground-based observational data relevant for ACTRIS

ACTRIS DC shall provide access to external data holdings and repositories of ground-based observations commonly used by ACTRIS users, valuable when combined with ACTRIS data. This functionality shall facilitate contextual analysis, inter-comparison, and validation purposes, and is required to produce derived products using multi-instrument synergetic retrieval algorithms. These regional and global networks and initiatives include EMEP, GAW, AERONET and NDACC.

4.4.2 Collocation service of data from regional and global networks

ACTRIS DC shall offer comprehensive data products combining ACTRIS data with data from regional and global networks, based on the functionality described in section 4.4.1. ACTRIS DC will offer yearly updates of benchmark data products adding complementary data from GAW and EMEP together with ACTRIS data e.g. ACTRIS variables presented together with PM and/or sulphate at the ACTRIS National Facilities. This will also provide data sets with global coverage, employing ACTRIS methods on data from sites outside Europe. The selection of variables can be made upon user requests, regulated through review process controlled by SAMU. See annex II for more details.

4.4.3 Aerosol remote sensing data – combination of variables and instruments from global networks

ACTRIS DC shall provide level 3 products derived from the standard AERONET products. Based on NASA algorithms, including AERONET Level 1 (Synergy or Single) data: Spectral refractive indexes, spectral extinction/absorption AOD, single scattering albedo, spectral LIDAR ratio, Ångström exponent, volume size distribution and spherical fraction. Furthermore, ACTRIS DC shall offer Direct Sun/Moon Extinction Aerosol Optical Depth (column) from AERONET, and Column Water Vapour Content.
4.4.4 PM retrieval @GAW sites globally

ACTRIS DC will utilize ACTRIS procedures and data to develop a methodology for estimating particulate mass at GAW sites, not yet generally available, through a combination of nephelometer measurements and size distribution. This will be used at all GAW sites to enable a yearly updated global PM product, together with complementary variables also included in ACTRIS. See annex II for more details.

4.4.5 Satellite data – combined with ground based ACTRIS data

ACTRIS DC shall provide access to external open data holdings of satellite measurements and retrievals commonly used by ACTRIS users combined with ACTRIS data, for contextual analysis, inter-comparison, or to produce derived products using multi-instrument synergetic retrieval algorithms. These external data bases include major product suites from the A-Train satellites (Terra/MODIS, Aqua/MODIS, PARASOL, CALIPSO, CloudSat, Aura/OMI, and Terra/MISR), Envisat/AATSR, IASI, and MSG/SEVIRI.

Due to the complexity of the geometry and orbital pattern of satellite sensors, the data centre will provide collocation tools capable to subset satellite data spatially and temporally with ACTRIS ground-based measurements.
4.4.4 PM retrieval @GAW sites globally

ACTRIS DC will utilize ACTRIS procedures and data to develop a methodology for estimating particulate mass at GAW sites, not yet generally available, through a combination of nephelometer measurements and size distribution. This will be used at all GAW sites to enable a yearly updated global PM product, together with complementary variables also included in ACTRIS. See annex II for more details.

4.4.5 Satellite data – combined with ground based ACTRIS data

ACTRIS DC shall provide access to external open data holdings of satellite measurements and retrievals commonly used by ACTRIS users combined with ACTRIS data, for contextual analysis, inter-comparison, or to produce derived products using multi-instrument synergetic retrieval algorithms. These external data bases include major product suites from the A-Train satellites (Terra/MODIS, Aqua/MODIS, PARASOL, CALIPSO, CloudSat, Aura/OMI, and Terra/MISR), Envisat/AATSR, IASI, and MSG/SEVIRI.

Due to the complexity of the geometry and orbital pattern of satellite sensors, the data centre will provide collocation tools capable to subset satellite data spatially and temporally with ACTRIS ground-based measurements.
## 4.5 Production of ACTRIS level 3 data products involving regional and global model data

### 4.5.1 Aerosol and Gas trend assessment

ACTRIS DC shall produce and provide level 3 products based on ACTRIS level 2 data comprising:

* best estimates of trends in atmospheric composition of components covered by ACTRIS

* display of complementary multi-annual information from models and/or satellites from hindcasts or reanalysis

* web visualisation of trends at individual stations as well as for regions

* regular biennial trend assessments based on updated information

### 4.5.2 Data Interpretation and Outlier Identification Tool

ACTRIS DC shall offer automated assessments of ACTRIS data quality using assimilation model products, model climatologies and satellite data for intercomparison with ACTRIS data. The centre should in particular:

* Collocate model data such that outliers in ACTRIS data products become apparent and can be investigated further

* Provide a visualization and download tool to allow data interpretation with model information (e.g. meteorological parameters, non-observable atmospheric chemistry parameters, source contributions from sectors or regions)

### 4.5.3 Optimal interpolation and Gap filling tool

ACTRIS DC must produce tools that enable the merging of observational and model data to produce continuous data products both in space and time. In particular it should:

* Fill gaps in incomplete time series, profiles of ACTRIS data products to allow for the production of climatologies, trends, spatial distribution

* Allow for the optimal interpolation or assimilation of data into assimilation systems, and provide access to the assimilation products derived
## 4.5 Production of ACTRIS level 3 data products involving regional and global model data

### 4.5.1 Aerosol and Gas trend assessment

ACTRIS DC shall produce and provide level 3 products based on ACTRIS level 2 data comprising:

* best estimates of trends in atmospheric composition of components covered by ACTRIS

* display of complementary multi-annual information from models and/or satellites from hindcasts or reanalysis

* web visualisation of trends at individual stations as well as for regions

* regular biennial trend assessments based on updated information

### 4.5.2 Data Interpretation and Outlier Identification Tool

ACTRIS DC shall offer automated assessments of ACTRIS data quality using assimilation model products, model climatologies and satellite data for intercomparison with ACTRIS data. The centre should in particular:

* Collocate model data such that outliers in ACTRIS data products become apparent and can be investigated further

* Provide a visualization and download tool to allow data interpretation with model information (e.g. meteorological parameters, non-observable atmospheric chemistry parameters, source contributions from sectors or regions)

### 4.5.3 Optimal interpolation and Gap filling tool

ACTRIS DC must produce tools that enable the merging of observational and model data to produce continuous data products both in space and time. In particular it should:

* Fill gaps in incomplete time series, profiles of ACTRIS data products to allow for the production of climatologies, trends, spatial distribution

* Allow for the optimal interpolation or assimilation of data into assimilation systems, and provide access to the assimilation products derived
#### 4.5.4 Model Evaluation Service

ACTRIS DC must produce and provide level 3 data and services based on ACTRIS level 2 data for enabling model evaluation. In particular the centre should:

* foster the preparation of specific model evaluation benchmark datasets, with appropriate documentation

* provide web services for interactive model evaluation e.g. AeroCom, CMIP, ICAP, SDSWAS and NWP models based on ACTRIS data

* make available advanced visualization of model data comparisons on all levels, with free access to users

* automate model evaluation to provide fast feedback to model development

#### 4.5.5 Transport modelling products for assessment of source regions at the NFs

ACTRIS DC must produce inversion products built on backward transport modelling and tools to enable backward modelling operationally and automatically on a regular basis, e.g. monthly, for every site and platform. The results (both data and plots) should be made publicly available via an ACTRIS access interface so that they are readily accessible and can be used in the interpretation of the most recent measurement data.

#### 4.5.6 Alert Service for National Facilities

ACTRIS DC must offer tools for exploiting the potential of current chemical weather forecasting systems to help national facilities and campaigns in resource efficient management of measurement capacity. Alerts shall be send to interested users and experimental campaign managers based on variable criteria (e.g. dust plumes, winter inversions or clean air approaching).

### 4.6 Production of level 3 data ACTRIS data products from simulation chamber experiments

ACTRIS DC is required to provide level 3 data products derived from simulation chamber experiments. These advanced data products will be used by researchers working on atmospheric observations and atmospheric model development and validation. This includes products for the development of chemical processes in atmospheric models, products for satellite retrievals and for radiative transfer modelling, e.g. rate constants for gas and condensed phase reactions, mass extinction coefficients of aerosols, absorption cross sections and Secondary Organic Aerosol yields.

These data are produced by NF after level 2.5 data processing. ACTRIS DC will offer the data curation service and long term archive and can also provide tools for data visualisation and treatment. Level 3 data from exploratory platforms are not shown in annex II.

### 4.7 Service to campaigns

ACTRIS DC need to provide appropriate service and support related to campaigns. Application and access to this service will be a part of a review process managed by SAMU. Services may be offered free or for a
#### 4.5.4 Model Evaluation Service

ACTRIS DC must produce and provide level 3 data and services based on ACTRIS level 2 data for enabling model evaluation. In particular the centre should:

* foster the preparation of specific model evaluation benchmark datasets, with appropriate documentation

* provide web services for interactive model evaluation e.g. AeroCom, CMIP, ICAP, SDSWAS and NWP models based on ACTRIS data

* make available advanced visualization of model data comparisons on all levels, with free access to users

* automate model evaluation to provide fast feedback to model development

#### 4.5.5 Transport modelling products for assessment of source regions at the NFs

ACTRIS DC must produce inversion products built on backward transport modelling and tools to enable backward modelling operationally and automatically on a regular basis, e.g. monthly, for every site and platform. The results (both data and plots) should be made publicly available via an ACTRIS access interface so that they are readily accessible and can be used in the interpretation of the most recent measurement data.

#### 4.5.6 Alert Service for National Facilities

ACTRIS DC must offer tools for exploiting the potential of current chemical weather forecasting systems to help national facilities and campaigns in resource efficient management of measurement capacity. Alerts shall be send to interested users and experimental campaign managers based on variable criteria (e.g. dust plumes, winter inversions or clean air approaching).

### 4.6 Production of level 3 data ACTRIS data products from simulation chamber experiments

ACTRIS DC is required to provide level 3 data products derived from simulation chamber experiments. These advanced data products will be used by researchers working on atmospheric observations and atmospheric model development and validation. This includes products for the development of chemical processes in atmospheric models, products for satellite retrievals and for radiative transfer modelling, e.g. rate constants for gas and condensed phase reactions, mass extinction coefficients of aerosols, absorption cross sections and Secondary Organic Aerosol yields.

These data are produced by NF after level 2.5 data processing. ACTRIS DC will offer the data curation service and long term archive and can also provide tools for data visualisation and treatment. Level 3 data from exploratory platforms are not shown in annex II.

### 4.7 Service to campaigns

ACTRIS DC need to provide appropriate service and support related to campaigns. Application and access to this service will be a part of a review process managed by SAMU. Services may be offered free or for a
fee, depending on the request, and the work foreseen. The following sections outline the possible
campaign services that may be provided.

4.7.1 Digital tools and products for campaign support

For campaigns, the ACTRIS data centre will offer a centralised support website for providing relevant services, once agreements and contracts have been established.

4.7.1.1 Campaign dashboard

During intense observation periods, scientists require up-to-date information from multiple sources in order to schedule their measurements. These data are heterogeneous: images, documents, web services (e.g. OGC services), sensor and model data files. The website shall automatically harvest and compile in near real time all required data in a global dashboard. Manual upload of data will also be possible.

In addition, added value services may be provided such as

* trajectory forecast, flight plan tools,

* back trajectories for source regions and source analysis

4.7.1.2 Data curation and archive of campaign data

ACTRIS DC may offer data curation service and long term archive of data from campaigns. Application and access to this service will be a part of a review process managed by SAMU. Services may be offered free or for a fee, depending on the request, and the work foreseen.

Datasets acquired during the campaign must follow the ACTRIS data lifecycle:

* Identification (DOI)

* Cataloguing and harvesting

* Data discovery (including data preview)

* Public distribution according to ACTRIS Data policy

* Data usage statistics

* Long term preservation

However, the DC requires the tools necessary to offer to setup a specific website. It will be mainly
dedicated to the campaign community and will offer extra features for the data providers:

* Metadata edition

* Dataset upload

* Restricted distribution of not-validated data during the post campaign period

* User management

CMS features (news publication, statics pages, document upload)

4.8 User community support and services

As a tool for science, the highest priorities for the ACTRIS Data Centre is to compile data, and maintain and
increase the availability of ACTRIS data and data products relevant to climate and air quality research for
all interested users.
fee, depending on the request, and the work foreseen. The following sections outline the possible
campaign services that may be provided.

4.7.1 Digital tools and products for campaign support

For campaigns, the ACTRIS data centre will offer a centralised support website for providing relevant services, once agreements and contracts have been established.

4.7.1.1 Campaign dashboard

During intense observation periods, scientists require up-to-date information from multiple sources in order to schedule their measurements. These data are heterogeneous: images, documents, web services (e.g. OGC services), sensor and model data files. The website shall automatically harvest and compile in near real time all required data in a global dashboard. Manual upload of data will also be possible.

In addition, added value services may be provided such as

* trajectory forecast, flight plan tools,

* back trajectories for source regions and source analysis

4.7.1.2 Data curation and archive of campaign data

ACTRIS DC may offer data curation service and long term archive of data from campaigns. Application and access to this service will be a part of a review process managed by SAMU. Services may be offered free or for a fee, depending on the request, and the work foreseen.

Datasets acquired during the campaign must follow the ACTRIS data lifecycle:

* Identification (DOI)

* Cataloguing and harvesting

* Data discovery (including data preview)

* Public distribution according to ACTRIS Data policy

* Data usage statistics

* Long term preservation

However, the DC requires the tools necessary to offer to setup a specific website. It will be mainly
dedicated to the campaign community and will offer extra features for the data providers:

* Metadata edition

* Dataset upload

* Restricted distribution of not-validated data during the post campaign period

* User management

CMS features (news publication, statics pages, document upload)

4.8 User community support and services

As a tool for science, the highest priorities for the ACTRIS Data Centre is to compile data, and maintain and
increase the availability of ACTRIS data and data products relevant to climate and air quality research for
all interested users.
### 4.8.1 ACTRIS Data provenance, attribution, and traceability

In an effort to spread good practise for attribution of data production efforts and traceability of data, ACTRIS offer the same routines to the user community for documenting data provenance as those used internally described in section 3.3.

### 4.8.2 Support to regional and global networks and related initiatives

ACTRIS will support international frameworks in the field of air quality and climate change, e.g., GAW, EMEP, GALION, and GCOS, and further utilize and add value to satellite based atmospheric observations. It is a requirement that the ACTRIS data centre supports GAW and the EMEP program by contributing with required scientific and technological expertise in relation to atmospheric observations, and will also offer tools and data curation facilities to improve and ensure the harmonization and standardization of data and meta-data. This will ensure impacts and harmonization on both a regional and global scale. Specifically, it is required that ACTRIS support ongoing efforts made by the EMEP Chemical Coordinating Centre, and of the EMEP Task Force on Measurements and Modelling, as well as relevant bodies and institutions engaged in Global Atmosphere Watch (i.e. http://www.wmo.int/pages/prog/arep/gaw).

### 4.8.3 Interoperability and link to other RIs and initiatives

Interoperability in ACTRIS shall be guided by the [FAIR Data Principles](#) Findable, Accessible, Interoperable, Re-Usable laid out by the [FORCE11 community](#). In ACTRIS, these will be implemented by the following measures:

**Findable:** All ACTRIS data shall be uniquely identified by DOIs (identification requirement). ACTRIS data shall be accompanied by a comprehensive set of metadata including discovery, quality, uncertainty, and production process metadata, including a complete provenance record (rich metadata requirement). ACTRIS data have to be registered with domain relevant higher level frameworks facilitating their discovery for re-use, which includes the European Open Science Cloud (EOSC), the Global Earth Observation System of Systems (GEOSS), the WMO Integrated Global Observing System (WIGOS), and the EU Copernicus Atmospheric Services (CAMS) (indexing requirement). Mutual data discovery also includes the European atmospheric RIs IAGOS and ICOS.

**Accessible:** ACTRIS data and metadata shall be accessible by domain-specific standardised machine-to-machine interfaces. Metadata can be served via the [OAI-PMH protocol](#). Data shall be served via e.g. the [OPeNDAP](#) and [OGC](#) protocols. A [World Wide Web Consortium (W3C)](https://www.w3.org/) endorsed [SPARQL](#) endpoint can be considered. By definition, ACTRIS data DOIs point to the human- and machine-readable interfaces of the dataset.

**Interoperable:** The metadata interface deploys the standardised, community specific and WMO endorsed metadata profiles of the [WMO Information System (WIS)](#) and WIGOS, with vocabularies of the [Climate and Forecast (CF)](#) conventions and WIGOS. The data services make use of the [NetCDF](#) format, which is commonly used in the atmospheric community.
4.8.1 ACTRIS Data provenance, attribution, and traceability

In an effort to spread good practise for attribution of data production efforts and traceability of data, ACTRIS offer the same routines to the user community for documenting data provenance as those used internally described in section 3.3.

4.8.2 Support to regional and global networks and related initiatives

ACTRIS will support international frameworks in the field of air quality and climate change, e.g., GAW, EMEP, GALION, and GCOS, and further utilize and add value to satellite based atmospheric observations. It is a requirement that the ACTRIS data centre supports GAW and the EMEP program by contributing with required scientific and technological expertise in relation to atmospheric observations, and will also offer tools and data curation facilities to improve and ensure the harmonization and standardization of data and meta-data. This will ensure impacts and harmonization on both a regional and global scale. Specifically, it is required that ACTRIS support ongoing efforts made by the EMEP Chemical Coordinating Centre, and of the EMEP Task Force on Measurements and Modelling, as well as relevant bodies and institutions engaged in Global Atmosphere Watch (i.e. http://www.wmo.int/pages/prog/arep/gaw).

4.8.3 Interoperability and link to other RIs and initiatives

Interoperability in ACTRIS shall be guided by the [FAIR Data Principles](#) Findable, Accessible, Interoperable, Re-Usable laid out by the [FORCE11 community](#). In ACTRIS, these will be implemented by the following measures:

**Findable:** All ACTRIS data shall be uniquely identified by DOIs (identification requirement). ACTRIS data shall be accompanied by a comprehensive set of metadata including discovery, quality, uncertainty, and production process metadata, including a complete provenance record (rich metadata requirement). ACTRIS data have to be registered with domain relevant higher level frameworks facilitating their discovery for re-use, which includes the European Open Science Cloud (EOSC), the Global Earth Observation System of Systems (GEOSS), the WMO Integrated Global Observing System (WIGOS), and the EU Copernicus Atmospheric Services (CAMS) (indexing requirement). Mutual data discovery also includes the European atmospheric RIs IAGOS and ICOS.

**Accessible:** ACTRIS data and metadata shall be accessible by domain-specific standardised machine-to-machine interfaces. Metadata can be served via the [OAI-PMH protocol](#). Data shall be served via e.g. the [OPeNDAP](#) and [OGC](#) protocols. A [World Wide Web Consortium (W3C)](https://www.w3.org/) endorsed [SPARQL](#) endpoint can be considered. By definition, ACTRIS data DOIs point to the human- and machine-readable interfaces of the dataset.

**Interoperable:** The metadata interface deploys the standardised, community specific and WMO endorsed metadata profiles of the [WMO Information System (WIS)](https://www.wmo.int/) and WIGOS, with vocabularies of the [Climate and Forecast (CF)](https://www.wmo.int/pages/prog/arep/gaw) conventions and WIGOS. The data services make use of the [NetCDF](#) format, which is commonly used in the atmospheric community.
**Re-usable:** Use of an open-access data policy, combined with a full documentation of provenance, and meeting community standards in data and metadata services and formats, ensures the re-usability of ACTRIS data.

#### 4.8.4 Knowledge transfer and training on the use of data products and tools

ACTRIS DC offers services devoted to the transfer of knowledge addressed to the heterogeneous expected user community: from scientists to local authorities and citizens at large.

Fostering the international scientific cooperation, training activities addressed to scientific community about the use of offered data production and processing tools are offered. Additionally, tutorials about the use and the correct interpretation of ACTRIS data from Lev1 to Lev 3 are offered. The tutorials shall be specifically addressed to the different communities, so replying to the specific needs related to the background expertise and knowledge of the different users.

## 5 Organization and management structure of the ACTRIS Data Centre

All ACTRIS Central Facilities (CFs) shall be organized according to the role of the specific CF, ensuring that the CF complies with the requirements and obligations described in section 6 and 8 of this document, and considering the general principles described in the *Baseline document for the concept of the Central Facilities*. The ACTRIS Data Centre (ACTRIS DC) shall be organized such that:

* It has a well-defined structure of Units,

* It has a well-defined links, procedures and structure for interaction between any DC Units, and TCs and NFs

* It has a well-defined decision-making process,

* It is coordinated by a CF Director and managed by a CF Management Board, which consists of the CF Director and the CF Unit Heads,

* It has clear and cost-efficient task sharing between the Units,

* It has a risk management strategy,

* It participates in the ACTRIS decision making by sending representative(s) to the ACTRIS legal entity bodies, e.g. to the RI committee.

## 6 Requirements for the ACTRIS Data Centre

### 6.1 General requirements for Central Facilities

ACTRIS Data Centre shall:

* Commit for long-term operation (at least 10 years)

* Ensure appropriate links between the various activities to ensure a robust, cost-effective and functional data centre,

* Document the capacity in terms of material and personnel resources, to ensure the provision of the requested services and operation support, as described in section 6.2
**Re-usable:** Use of an open-access data policy, combined with a full documentation of provenance, and meeting community standards in data and metadata services and formats, ensures the re-usability of ACTRIS data.

#### 4.8.4 Knowledge transfer and training on the use of data products and tools

ACTRIS DC offers services devoted to the transfer of knowledge addressed to the heterogeneous expected user community: from scientists to local authorities and citizens at large.

Fostering the international scientific cooperation, training activities addressed to scientific community about the use of offered data production and processing tools are offered. Additionally, tutorials about the use and the correct interpretation of ACTRIS data from Lev1 to Lev 3 are offered. The tutorials shall be specifically addressed to the different communities, so replying to the specific needs related to the background expertise and knowledge of the different users.

## 5 Organization and management structure of the ACTRIS Data Centre

All ACTRIS Central Facilities (CFs) shall be organized according to the role of the specific CF, ensuring that the CF complies with the requirements and obligations described in section 6 and 8 of this document, and considering the general principles described in the *Baseline document for the concept of the Central Facilities*. The ACTRIS Data Centre (ACTRIS DC) shall be organized such that:

* It has a well-defined structure of Units,

* It has a well-defined links, procedures and structure for interaction between any DC Units, and TCs and NFs

* It has a well-defined decision-making process,

* It is coordinated by a CF Director and managed by a CF Management Board, which consists of the CF Director and the CF Unit Heads,

* It has clear and cost-efficient task sharing between the Units,

* It has a risk management strategy,

* It participates in the ACTRIS decision making by sending representative(s) to the ACTRIS legal entity bodies, e.g. to the RI committee.

## 6 Requirements for the ACTRIS Data Centre

### 6.1 General requirements for Central Facilities

ACTRIS Data Centre shall:

* Commit for long-term operation (at least 10 years)

* Ensure appropriate links between the various activities to ensure a robust, cost-effective and functional data centre,

* Document the capacity in terms of material and personnel resources, to ensure the provision of the requested services and operation support, as described in section 6.2
* Provide a feasible implementation and operation plan for the first five years, starting with the first year after the selection as CF.

## 6.2 Specific requirements for ACTRIS Data Centre

ACTRIS DC must comply with these requirements:

* Answer to specific needs for data curation for the methodologies applied by ACTRIS NF;

* Provide virtual access to ACTRIS data, services and tools via the ACTRIS data user interface

* If the ACTRIS Data Centre is distributed across different nodes, demonstrate close interaction between the nodes.

* Employ standardized nomenclature Climate and Forecast Metadata nomenclature (CF)

* Implement standardised meta data exchange protocols across the RI to ensure interoperability with other RIs and frameworks (e.g. WIGOS, GEOSS, and EOSC).

* Offer access to measurement data compliant with FAIR principles (FORCE11)

* Offer legally binding license systems to regulate the conditions of use and facilitate open data access common over the infrastructure

* Commit to provide the mandatory operation support to the ACTRIS NFs, as described in section 3

* Commit to provide mandatory core services listed in section 4 to the ACTRIS internal and external users

* Commit to provide the mandatory operation support to the ACTRIS NFs, as described in section 3.

* Commit to provide user services, as described in section 4

* Commit to offering virtual access to data and services to ACTRIS users as close to 24/7 as possible.

* Operate a secure and robust ICT infrastructure.

* Implement an information security policy

The information security policy must detail the measures taken to ensure data security by protecting data from being destroyed by either accidents or through deliberate actions by unauthorised users (cyberattacks). Data protection includes security procedures and backup procedures. In particular, the backup procedures must contain the following:

* Well-defined regular and frequent back up schedule

* Off-line backup requiring manual interaction

* Off-site data protection, where the archive is in a different location to the operational servers

* A disaster recovery plan

All data must be stored in such a way to:

* ensure the long term archival of all data products and pre-products produced in the associated workflow

* ensure long term archival of all QA and QC documents produced and referenced in the metadata

* ensure long term archival of any value-added services and references related to the data products
* Provide a feasible implementation and operation plan for the first five years, starting with the first year after the selection as CF.

## 6.2 Specific requirements for ACTRIS Data Centre

ACTRIS DC must comply with these requirements:

* Answer to specific needs for data curation for the methodologies applied by ACTRIS NF;

* Provide virtual access to ACTRIS data, services and tools via the ACTRIS data user interface

* If the ACTRIS Data Centre is distributed across different nodes, demonstrate close interaction between the nodes.

* Employ standardized nomenclature Climate and Forecast Metadata nomenclature (CF)

* Implement standardised meta data exchange protocols across the RI to ensure interoperability with other RIs and frameworks (e.g. WIGOS, GEOSS, and EOSC).

* Offer access to measurement data compliant with FAIR principles (FORCE11)

* Offer legally binding license systems to regulate the conditions of use and facilitate open data access common over the infrastructure

* Commit to provide the mandatory operation support to the ACTRIS NFs, as described in section 3

* Commit to provide mandatory core services listed in section 4 to the ACTRIS internal and external users

* Commit to provide the mandatory operation support to the ACTRIS NFs, as described in section 3.

* Commit to provide user services, as described in section 4

* Commit to offering virtual access to data and services to ACTRIS users as close to 24/7 as possible.

* Operate a secure and robust ICT infrastructure.

* Implement an information security policy

The information security policy must detail the measures taken to ensure data security by protecting data from being destroyed by either accidents or through deliberate actions by unauthorised users (cyberattacks). Data protection includes security procedures and backup procedures. In particular, the backup procedures must contain the following:

* Well-defined regular and frequent back up schedule

* Off-line backup requiring manual interaction

* Off-site data protection, where the archive is in a different location to the operational servers

* A disaster recovery plan

All data must be stored in such a way to:

* ensure the long term archival of all data products and pre-products produced in the associated workflow

* ensure long term archival of all QA and QC documents produced and referenced in the metadata

* ensure long term archival of any value-added services and references related to the data products
* ensure consistency and unambiguousness of data and metadata, harmonised across the RI and, if applicable, with other relevant frameworks

* enable traceability of changes in the archive (deletions, updates, corrections) and reproducibility of historic data holdings

ACTRIS data curation requests the following operational requirements

* Ensure sufficient availability of the system, above 90% of the time is the ambition

* Monitoring of databases, data flows and system performance. Downtimes of components must be detected and escalated to technical staff automatically.

* Availability and response times of the web interface

* Detect backlogs and errors in submitted files.

* Analyse critical system components and define backup schedules for the different components. Typically, daily backups should be available.

### 6.2.1 Additional requirements of ACTRIS in situ aerosol, cloud and trace gas data services

ACTRIS in situ data curation requests the following additional operational requirement:

* Monitoring of databases and system:

* Performance of the RRT dataflow

The ACTRIS in situ data curation and data base system must scale to handle

* Ca. 1000 QA files submitted per year (ca. 30 GiB)

* In addition, ca 30-50 RRT instruments is scheduled to submit approximately 300 000 files yearly.

* Overall, approximately 100-200 unique users use the system's web interface for data submission, about 1000-1500 unique users access data.

* Typically, between 1000 and 3000 instruments years of data are accessed per month.

The data archive for level 2 data is suited for a relational database system keeping all metadata and measurement data in one database. The data model is specialized for in situ time series. The database should support historic storage of data, so that the full history of changes can be traced at any time. Historic data content can be reproduced even if the data have been deleted or updated (corrected) in the archive.

The database is hosted on a dedicated database server. The web interface can be implemented with e.g. dot.net web application that accesses the archive database directly. The web application can e.g. use AJAX technology to achieve a more dynamic user experience.

The web application can be hosted on a dedicated web server. The data curation tasks, including the data ingestion, are performed using command line tools to interface with the database system. A dedicated Linux server is reserved for those tasks. For the RRT dataflow, a customized dataflow control software is used.
* ensure consistency and unambiguousness of data and metadata, harmonised across the RI and, if applicable, with other relevant frameworks

* enable traceability of changes in the archive (deletions, updates, corrections) and reproducibility of historic data holdings

ACTRIS data curation requests the following operational requirements

* Ensure sufficient availability of the system, above 90% of the time is the ambition

* Monitoring of databases, data flows and system performance. Downtimes of components must be detected and escalated to technical staff automatically.

* Availability and response times of the web interface

* Detect backlogs and errors in submitted files.

* Analyse critical system components and define backup schedules for the different components. Typically, daily backups should be available.

## 6.2.1 Additional requirements of ACTRIS in situ aerosol, cloud and trace gas data services

ACTRIS in situ data curation requests the following additional operational requirement:

* Monitoring of databases and system:

* Performance of the RRT dataflow

The ACTRIS in situ data curation and data base system must scale to handle

* Ca. 1000 QA files submitted per year (ca. 30 GiB)

* In addition, ca 30-50 RRT instruments is scheduled to submit approximately 300 000 files yearly.

* Overall, approximately 100-200 unique users use the system's web interface for data submission, about 1000-1500 unique users access data.

* Typically, between 1000 and 3000 instruments years of data are accessed per month.

The data archive for level 2 data is suited for a relational database system keeping all metadata and measurement data in one database. The data model is specialized for in situ time series. The database should support historic storage of data, so that the full history of changes can be traced at any time. Historic data content can be reproduced even if the data have been deleted or updated (corrected) in the archive.

The database is hosted on a dedicated database server. The web interface can be implemented with e.g. dot.net web application that accesses the archive database directly. The web application can e.g. use AJAX technology to achieve a more dynamic user experience.

The web application can be hosted on a dedicated web server. The data curation tasks, including the data ingestion, are performed using command line tools to interface with the database system. A dedicated Linux server is reserved for those tasks. For the RRT dataflow, a customized dataflow control software is used.
### 6.2.2 Additional requirements of ACTRIS aerosol remote sensing data services

ACTRIS aerosol remote sensing data curation request the following additional operational requirement:

* Implementation of the Single Calculus Chain (SCC); the automatic and traceable processing tool for the analysis of Level 0 up to Level 1 products.

The ACTRIS aerosol remote sensing data curation and data base system must scale to handle

* about 150000 Level 0 files be submitted per year (ca. 4 TB)

* about 500 unique users use the system's web interface for data submission, about 1000-1500 unique users access data.

* about 500 unique SCC users

The data archive for level 1 and level 2 data is suited for a relational database system keeping all metadata and measurement data in one database. The database should support historic storage of data, so that the full history of changes can be traced at any time. Historic data content can be reproduced even if the data have been deleted or updated (corrected) in the archive.

The database is hosted on a dedicated database server. The web interface can be implemented PHP, Java or Python web application that accesses the archive database directly.

The web application should be hosted on a dedicated web server. The data curation tasks, including the data ingestion, are performed using both web (graphical) interface and via API allowing command line tools to interface with the database system.

The SCC should be implemented at least on three different dedicated servers: one hosting the SCC database where all the processing parameters are collected and used in the analysis; a second one running and coordinating all the SCC calculus modules; and finally a third server on which the SCC web interface is implemented.

The servers hosting the SCC should be designed to allow the automatic generation of RRT and RRT Level 1 products.

### 6.2.3 Additional requirements of ACTRIS cloud remote sensing data services

ACTRIS cloud remote sensing data curation request the following operational requirements:

* Monitoring of databases and system:

* Performance of the NRT dataflow

* Performance of the NRT NWP model data flow

* Implementation of the Cloudnet processing scheme producing Level 1 and 2 products from Level 0 data, together with full traceability.

The ACTRIS cloud remote sensing data curation and database system must scale to handle
## 6.2.2 Additional requirements of ACTRIS aerosol remote sensing data services

ACTRIS aerosol remote sensing data curation request the following additional operational requirement:

* Implementation of the Single Calculus Chain (SCC); the automatic and traceable processing tool for the analysis of Level 0 up to Level 1 products.

The ACTRIS aerosol remote sensing data curation and data base system must scale to handle

* about 150000 Level 0 files be submitted per year (ca. 4 TB)

* about 500 unique users use the system's web interface for data submission, about 1000-1500 unique users access data.

* about 500 unique SCC users

The data archive for level 1 and level 2 data is suited for a relational database system keeping all metadata and measurement data in one database. The database should support historic storage of data, so that the full history of changes can be traced at any time. Historic data content can be reproduced even if the data have been deleted or updated (corrected) in the archive.

The database is hosted on a dedicated database server. The web interface can be implemented PHP, Java or Python web application that accesses the archive database directly.

The web application should be hosted on a dedicated web server. The data curation tasks, including the data ingestion, are performed using both web (graphical) interface and via API allowing command line tools to interface with the database system.

The SCC should be implemented at least on three different dedicated servers: one hosting the SCC database where all the processing parameters are collected and used in the analysis; a second one running and coordinating all the SCC calculus modules; and finally a third server on which the SCC web interface is implemented.

The servers hosting the SCC should be designed to allow the automatic generation of RRT and RRT Level 1 products.

## 6.2.3 Additional requirements of ACTRIS cloud remote sensing data services

ACTRIS cloud remote sensing data curation request the following operational requirements:

* Monitoring of databases and system:

* Performance of the NRT dataflow

* Performance of the NRT NWP model data flow

* Implementation of the Cloudnet processing scheme producing Level 1 and 2 products from Level 0 data, together with full traceability.

The ACTRIS cloud remote sensing data curation and database system must scale to handle
* about 50000 Level 0 files submitted per year (ca. 5 TB) rising to 10 TB per year once Doppler spectra are stored.

* About 50000 Level 1 and 2 files stored per year (ca. 5 TB)

The data volume required for storing Level 1 and 2 data suits a file-based system which interacts with a relational database containing pertinent metadata for discovery and version control. The database and file system should be hosted on a dedicated server, with data ingestion in NRT through a separate dedicated FTP/SFTP server. The Cloudnet processing scheme should be implemented on a dedicated Linux server, with fast (high bandwidth) access to the database/fileserver. This server also performs the data curation tasks, including the single instrument data pre-processing and interfaces with the database server.

The web application should be hosted on a separate dedicated web server, with access to the data via a web API, which can be written in PHP and/or Python.

The servers hosting the cloud remote sensing database infrastructure should be designed to allow the automatic generation of NRT and RRT Level 1 and 2 products.

### 6.2.4 Additional requirements of ACTRIS trace gas remote sensing data

The volume of the prosed data sets is currently less than 1GB so that the data curation and database system do not need special requirements. The data processing scheme requires a dedicated server, with fast (high bandwidth) access to the database/fileserver. More clarifications and requirements will be made in 2018.

### 6.2.5 Additional requirements of ACTRIS atmospheric simulation chamber data services

#### 1.1.1.6 Facilities and requirements related to repositories and data curation

The ACTRIS atmospheric simulation chamber data are organized within three databases as described in section 3.5.1.1. The data products are stored in their own data model and original data formats. The database administration must trace the statistics of the database consultation.

The ACTRIS atmospheric simulation chamber data curation and database system must scale to manage all the data products collected during the time of the project and after (150 to 250 data sets – ca. 10 GB).

The web application is hosted on a dedicated web server, the data curation tasks including the data and metadata ingestion are performed using dedicated graphical web interfaces. A neutral client-side technology (web components, http://fr.wikipedia.fr/wiki/Composants_web) which allows developing custom rich html tags has been used to develop these interfaces. Concerning the data and metadata products, they are hosted on a dedicated database server (historical data and updates). Through the web interface, web applications permit to access the databases directly using RESTful requests.
* about 50000 Level 0 files submitted per year (ca. 5 TB) rising to 10 TB per year once Doppler spectra are stored.

* About 50000 Level 1 and 2 files stored per year (ca. 5 TB)

The data volume required for storing Level 1 and 2 data suits a file-based system which interacts with a relational database containing pertinent metadata for discovery and version control. The database and file system should be hosted on a dedicated server, with data ingestion in NRT through a separate dedicated FTP/SFTP server. The Cloudnet processing scheme should be implemented on a dedicated Linux server, with fast (high bandwidth) access to the database/fileserver. This server also performs the data curation tasks, including the single instrument data pre-processing and interfaces with the database server.

The web application should be hosted on a separate dedicated web server, with access to the data via a web API, which can be written in PHP and/or Python.

The servers hosting the cloud remote sensing database infrastructure should be designed to allow the automatic generation of NRT and RRT Level 1 and 2 products.

### 6.2.4 Additional requirements of ACTRIS trace gas remote sensing data

The volume of the prosed data sets is currently less than 1GB so that the data curation and database system do not need special requirements. The data processing scheme requires a dedicated server, with fast (high bandwidth) access to the database/fileserver. More clarifications and requirements will be made in 2018.

### 6.2.5 Additional requirements of ACTRIS atmospheric simulation chamber data services

#### 1.1.1.6 Facilities and requirements related to repositories and data curation

The ACTRIS atmospheric simulation chamber data are organized within three databases as described in section 3.5.1.1. The data products are stored in their own data model and original data formats. The database administration must trace the statistics of the database consultation.

The ACTRIS atmospheric simulation chamber data curation and database system must scale to manage all the data products collected during the time of the project and after (150 to 250 data sets – ca. 10 GB).

The web application is hosted on a dedicated web server, the data curation tasks including the data and metadata ingestion are performed using dedicated graphical web interfaces. A neutral client-side technology (web components, http://fr.wikipedia.fr/wiki/Composants_web) which allows developing custom rich html tags has been used to develop these interfaces. Concerning the data and metadata products, they are hosted on a dedicated database server (historical data and updates). Through the web interface, web applications permit to access the databases directly using RESTful requests.
6.2.6 Additional requirements to the ACTRIS data user interface and access service

In contrast to lower data levels, level 3 data products may have arbitrary data structure and file formats.
Thus, it is not required that these data products are stored in one unified data model, but rather in their
original file formats. It is required that the data are accessible through the ACTRIS data user interface.

The archiving of these data files and the administration of their metadata must be performed in
appropriate systems. In particular, the administration of DOIs and the related metadata are crucial:

* A suitable document archiving system / publishing system to archive the products

* Minting of DOI's, registration including all necessary metadata

* Provide landing pages for DOI's

* Provide data access through DOI landing page

The architecture needs to:

* Ensure sufficient availability of the system and data products

* Ensure regular back up of the archive (daily), keep off-site backups, and develop disaster recovery plans.
6.2.6 Additional requirements to the ACTRIS data user interface and access service

In contrast to lower data levels, level 3 data products may have arbitrary data structure and file formats.
Thus, it is not required that these data products are stored in one unified data model, but rather in their
original file formats. It is required that the data are accessible through the ACTRIS data user interface.

The archiving of these data files and the administration of their metadata must be performed in
appropriate systems. In particular, the administration of DOIs and the related metadata are crucial:

* A suitable document archiving system / publishing system to archive the products

* Minting of DOI's, registration including all necessary metadata

* Provide landing pages for DOI's

* Provide data access through DOI landing page

The architecture needs to:

* Ensure sufficient availability of the system and data products

* Ensure regular back up of the archive (daily), keep off-site backups, and develop disaster recovery plans.
## 6.3 Expected human resources

Operating the ACTRIS Data Centre requires in total about 20 persons (Full Time Equivalent) with complementary skills and a broad background. The expected minimum human resources for offering the planned services are shown in Fig. 3 and listed in the table below, associated with the expected expertise required for fulfilling the various data centre services envisaged.

<figure><img src="image_8.png" /><figcaption>Figure 3: Expertise required for the various data centre services during operational phase, as described in section 3 and 4.</figcaption></figure>

<table><caption>Table 1: The expected minimum human resources and expertise required to offer the planned operational services.</caption><thead><tr><th rowspan="2"></th><th colspan="3">Management & administration staff</th><th colspan="3">Scientific & technical staff</th></tr><tr><th>Expert manager</th><th>Qualified officer</th><th>Administrative assistant</th><th>Scientific expert</th><th>Qualified operator</th><th>Technician</th></tr></thead><tbody><tr><td>ACTRIS data access and services: data access, tools, visualisations</td><td>0.2</td><td>0.0</td><td>0.0</td><td>1.4</td><td>0.0</td><td>1.8</td></tr><tr><td>ACTRIS level 3 data combining various data and sources</td><td>0.2</td><td>0.0</td><td>0.0</td><td>0.6</td><td>1.2</td><td>0.1</td></tr></tbody></table>
## 6.3 Expected human resources

Operating the ACTRIS Data Centre requires in total about 20 persons (Full Time Equivalent) with complementary skills and a broad background. The expected minimum human resources for offering the planned services are shown in Fig. 3 and listed in the table below, associated with the expected expertise required for fulfilling the various data centre services envisaged.

<figure><img src="image_9.png" /><figcaption>Figure 3: Expertise required for the various data centre services during operational phase, as described in section 3 and 4.</figcaption></figure>

<table><caption>Table 1: The expected minimum human resources and expertise required to offer the planned operational services.</caption><thead><tr><th rowspan="2"></th><th colspan="3">Management & administration staff</th><th colspan="3">Scientific & technical staff</th></tr><tr><th>Expert manager</th><th>Qualified officer</th><th>Administrative assistant</th><th>Scientific expert</th><th>Qualified operator</th><th>Technician</th></tr></thead><tbody><tr><td>ACTRIS data access and services: data access, tools, visualisations</td><td>0.2</td><td>0.0</td><td>0.0</td><td>1.4</td><td>0.0</td><td>1.8</td></tr><tr><td>ACTRIS level 3 data combining various data and sources</td><td>0.2</td><td>0.0</td><td>0.0</td><td>0.6</td><td>1.2</td><td>0.1</td></tr></tbody></table>