Storage documentation in PDF form: Datei:Storage Module.pdf‎

Synopsis

The Storage module is responsible for saving data in the lidar system which will be accessed by users at some future time. It should consist of a device which can rapidly and safely store data over a long period of time, and one which is easily interfaceable with external controllers like a PC. It has two roles: Storing Data and Saving Data, both of which need to be accomplished at speeds higher than or equal to the rate at which data is being processed to ensure that no data is lost.

Glossary of Terms

1. SSD: Solid State Drive

2. HDD: Hard Disk Drive

3. GUI: Graphical User Interface

4. SATA: Serial ATA; An interface standard for storage devices on computers

5. PCI: A standard for connecting computers and their peripherals

Design Requirements

This section includes the objectives and constraints of the Storage module.

1. Data must be able to be written at rates greater than the rate at which data is being processed by the internal controller

2. Data must be able to be read at rates greater than the rate at which data is being processed by the internal controller to provide real time information to the user

3. At least a year’s worth of data from the system must be able to be held at any given time

4. Data must be able to be remotely accessed, read, and manipulated

Safety

This section describes the safety concerns of the Storage module, and suggestions for mitigating any possible risks.

The storage module must have insulated power outlets in order to ensure that no electrical sparking or shocks are inflicted on individuals manipulating the system. On top of this, it must be robust enough to not lose any data or functionality while in the operating conditions of the lidar device.

High Level Overview

This section will discuss the main functions of the Storage module and its constituent components.

As can be seen in Figure 1 below, the Storage module has two main roles: Saving Data and Sharing Data. These two roles have similar design needs and need to be integrated well with the Control module in order to ensure fast, efficient, and robust data transfer throughout the lidar and to the outside world.

Figure 1: System diagram of the Storage Module

Low Level Information

This section will discuss the details of the Storage module, including the functions it needs to accomplish and suggestions on how to accomplish said functions. It is separated into the two main branches of the Storage module: Saving Data and Sharing Data.

Saving Data

Figure 2: Overview of Saving Data Branch

Figure 2 provides an overview of the Saving Data branch. The efficacy of a design for this branch can be judged based on two main metrics: how much and how often is data lost (in bits/s), and how fast can data be transferred to the module (in bits/s)

The criterion for the first point is, somewhat obviously, lower is better, and any design should strive for (and hopefully meet) the goal of zero data loss. The criteria for the second point include the speed at which data is transferred, with higher being better, and the ease of which the storage module can be interfaced with the rest of the system. A module which has high bit transfer rates but uses a unique, specialized, or otherwise complicated interface may not be a better design than one with slightly slower speeds but with common ports such as SATA or PCI. This acts to increase the modularity and support for the system as a whole, as well as to reduce costs (off the shelf products, as it were, are more suited for the OpenLidar project than custom machined ones). The constraints of this branch of the system are set by the data processing rate of the Internal Controller, as well as the industry standard for the amount of data that can be stored. Using the ZephIR 300 Wind Speed Lidar as a reference, the sampling rate of data is 50 Hz (or 50 writes per second) and, for 1 second averaging of data, 3MB of data is stored per day on this system(1). As such, we use these numbers as our standards. This system also allows for thirty-six months, or three years, of storage1. This number can be reduced to at least twelve months, or one year of storage, as the modularity of the system allows for varying classes of storage modules, which may include more storage space at a slightly higher cost. Furthermore, a full year of collected data seems like a reasonable amount of onboard storage for a base model system, particularly in one that will be used for research projects.

Sharing Data

Figure 3, below, provides an overview of the Sharing Data branch. The efficacy of the design for this branch depends on two main metrics: sharing data directly (in bits/s), sharing data remotely (in bits/s)

Both of these metrics are to be judged against the criterion of higher bit transfer rates are better, and also in the ease of transferring data (similarly to the Saving Data branch, common ports and protocols are preferred to custom ones). The main aspect of this branch is the ease of connectivity and use by users both remotely and from directly accessing the module. Data should be able to be streamed in real time (i.e. at the sampling rate of the lidar) and the user should be able to pick and choose the information they want to receive (e.g. just wind profiles, just information about the states of other modules, or a combination of the two).

Figure 3: Overview of Sharing Data Branch

Interfaces

Figure 4 shows the dependencies of the Storage module with the rest of the lidar system. The inputs and outputs are described in detail below. The descriptions are colour coded for ease of reading and transferring from diagram to text.

Figure 4: Dependency Map of Storage Module

Progress

This module is in the abstract definition phase, and information regarding power specific design (weight, dimensions, components, etc.) needs to be accomplished before prototyping can begin.

Testing

Type description of testing on module here.

Comments

It is suggested that an SSD be used over an HDD for this module for two reasons. First, SSDs have higher data transfer rates than HDDs, which is beneficial in these read/write intensive situations. Second, HDDs have moving parts which, in the operating conditions of some lidars (vibrations, etc.) introduce a potential for damage of the storage modules spinning disks. SSDs have no such parts, and are thus safer in these situations.

UML and One line diagrams need to be made for this module.

Storage module colour (Hex code): #351c75

Revision History

Description of Work	Date	Author
Synopsis, Glossary, Design Requirements, Safety, High Level Overview, Low Level Overview, Interfaces, Progress, Comments, and References completed	30.07.2015	Joshua Calafato
General edits to grammar and style	31.07.15	Joshua Calafato, Katherine Maul, Frank Modruson IV, Alan Yeh

References

1. Zephir Ltd. (2015). ZephIR Lidar (Brochure). England: Zephir Ltd. Retrieved from http://www.zephirlidar.com/wp-content/uploads/2015/03/ZephIR-Lidar-2015-brochure.pdf