Requirement Analysis

Purpose of this Chapter

The aim of this chapter is to explain the requirements of the system. It’s recommended to read this chapter to get a deeper understanding of the structures and principles.

Requirements - Deployments

Requirement A[01] - Projects

The database has to give the possibility to store projects. A project has a unique name, a long name, and a short description. Projects are always limited in time and have a project period. There are third-party funding projects (often only 3-4 years) and research infrastructures (often over more than 20 years). The database must make it possible to differentiate between third-party funding projects and research infrastructures.

Requirement A[02] - Deployments

The database has to give the possibility to store deployments. Deployments are limited in time and have a deployment period. The deployed component can be installed at a fixed measurement location or aboard a moving platform (e.g., an aircraft or ship). Furthermore, every deployment needs to be assigned to a project. It should not be possible that a deployment exists without an assigned project. During a deployment, several series can be recorded. Every recorded series must be assigned to the deployment. It should also be possible that a series can be assigned to a sub-component of the deployed component. With this approach, you can find out which series are affected if there is a defect component. Vice versa, you can also find out which part of the component is defective if there is an invalid series.

Requirement A[03] - Measurement locations

The database has to give the possibility to store fixed measurement locations. A fixed measurement location has a unique name, a short description, and a position. Furthermore, a location must be assigned to a country. A location has an availability period that records when the location was available for measurements. Note that fixed measurement locations do not include airports and can not be assigned to a flight.

Requirement A[04] - Airports

The database has to give the possibility to store airports. An airport has a unique name, a unique IATA code, and a unique position. Furthermore, an airport is assigned to a country and a region. In contrast to fixed measurement locations, the availability for measurements should not be manageable in the database. It should also not be possible that airports are used for deployments.

Requirement A[05] - Aircraft

The database has to give the possibility to store aircraft. An aircraft has a name, a registration code, a serial number, and an internal number. Every aircraft has an aircraft type and is assigned to an airline. Furthermore, an aircraft has an availability period that records when the aircraft was available for operations.

Requirement A[06] - Flights

The database has to give the possibility to store flights. Every flight is operated by an aircraft, has a flight period, a unique flight ID, and is assigned to a departure airport and an arrival airport. A flight can only be done if the departure and arrival are inside the aircraft’s availability period.

Requirement A[07] - Campaigns

The database has to give the possibility to store campaigns. Campaigns have a unique name, a campaign period, and a short description. Every campaign has several deployments. The campaigns are always a part of a project.

Requirements - Components

Requirement A[08] - Components

The database has to give the possibility to store components. Every component has a unique name and a short description. If several instances of a component type exist, they should always have the same name and description. The components differ only in the ID and the serial number. Furthermore, every component can have a status. With the status, you can mark temporarily defects of a component or that the component is in the warehouse. The status of a component is always is limited in time. With this approach, you can create a status history.

Requirement A[09] - Component relation

The database has to give the possibility to store relations between components. Therefore you have to define the components first and set them in relation afterwards. With this approach, the database maps every structure. A component relation has an installation timestamp, a removal timestamp, a component, a parent component, and the main component. In plain, it means that the component is installed in the parent component, and this relation can be assigned to the main component.

Requirement A[10] - Component installations

The database has to give the possibility to store installations. Besides the relation, it should be clear when the component was installed and what the component’s functionality is. For example, the same sensor type could be used by different components with different functionalities. For this reason, the functionality does depend on the parent component and the component type. Together with the relations, you have a history of where the component was already installed.

Requirement A[11] - Component classes

The database has to give the possibility to store component classes. Usually, the name of the component does not contain the category of the component. Therefore it should be possible to define classes and assign every component to a class. With this approach, you can classify your components and structure them well. It also helps to get a better overview of the components. For example, you can easily find out that the component PT100 is a sensor.

Requirement A[12] - Component parameters

The database has to make it possible to assign parameters to a component. With this, you can define that the PT100 records temperature. It should be possible to set the parameters only to the component type, and every component will inherit the parameter. Note that it should be possible that a component can also record several parameters. For example, the Package 2b records NO, NO2, and NOx.

Requirement A[13] - Parameters

Requirement A[14] - Calibrations

The database has to give the possibility to store calibrations. Some components need to be calibrated. Usually, this is done before and after the deployment. A calibration has a name, comments, a timestamp, and a component. The calibration parameters differ a lot, so it’s not possible to find a general calibration template. Therefore a solution is required that gives the possibility to assign individual calibration parameters.

Requirement A[15] - Calibration functions

The database has to give the possibility to store calibration functions. The deployments have a pre-calibration and a post-calibration. Usually, the calibration parameters drift during the deployment. The functions are used to reconstruct those shifts. These functions differ for any use case. Therefore, a solution is required that allows creating any mathematical function. Moreover, some functions consider the last calibrations to detect a trend. So it should also be possible that you can add calibration to the function.

Requirements - Series

Requirement A[16] - Time series

The database has to give the possibility to store time series. A time series has a name, a period, a creation timestamp, a description, and a revision. The creation timestamp records when the series was imported into the database. Every series should be assigned to a component, a parameter, and the related deployment.

Requirement A[17] - Data level

The database has to give the possibility to store data levels. A level describes the whole state of the time series. A level has a unique name and a short description. In the IAGOS projects, there are the three levels Raw data, Preliminary data, and Final data.

Requirement A[18] - Data points

The database has to give the possibility to store data points. A data point is assigned to a series, has a timestamp, a value, and validity. Furthermore, every data point can have additional information. These can be comments for the data point or additional values.

Requirement A[19] - Data validities

The database has to give the possibility to store data validities. Validity is used to mark a data point with a flag. A validity has a unique name and a description.