Skip to content

CSPS constraints_v 0.1

Nils Hamel edited this page Jan 9, 2015 · 1 revision

Overview

The CSPS library has to handle different type of incoming information and has the responsibility to process them in order to achieve a generic and precise positioning task. Because it is designed to handle any type of device in any number, the complexity of the library topology can increase quickly. This is the reason why the internal structure of the library is subject to strong constraints that are detailed here and that have to be followed.

Stream constraints

This section is devoted to constraints applied on streams. The streams, that can carry many components, have to follow the constraints defined here :

Synchronization constraint

Any stream own a synchronization component that stores CSPS timestamps. Each atomic value stored in an other component of the considered stream has to correspond to the timestamp value stored at the same offset in the synchronization component.

In other word, the number of timestamp values stored in the synchronization component has to be identical to the number of stored value in any other component of the considered stream and the relation between them has to be direct.

Module constraints

This section gives the constraints that apply on modules engaged in the CSPS library. In CSPS usage topology, modules are the nodes when stream are the links between nodes such that streams and modules have a fundamental relationship. In this context, the simplicity constraint is given :

Simplicity constraint

A module of CSPS library has to perform a specific and well identified task. In other words, modules are made to find solution for an atomic problem. The modules and streams topology is there to realize more complex tasks.

The following constraint is about module interface :

Interface constraints

About module input streams, each module name that have initiated streams that are considered as input by a given module have to be provided to it. Each module name is given once, even when more that one of its streams are considered as input by the considered module.

About output streams, each one has to take the name of the module that initiates them, even when a module create multiple output streams.

Those constraints are defined in order to keep libcsps as clean and easy to improve as possible, facilitating contributive development.


  [Home](Home)

  Section : device assembly

  • [CSPS device assembly](CSPS device assembly)

  Section : architecture

  • [CSPS architecture](CSPS architecture)

  Section : streams

  • [CSPS streams](CSPS streams)

  Section : extraction modules

  • [Module : cam-mod-DSIDE](Module cam-mod-DSIDE)
  • [Module : imu-mod-DSIDE](Module imu-mod-DSIDE)
  • [Module : gps-mod-DSIDE](Module gps-mod-DSIDE)

  Section : stream modules

  • [Module : gps-mod-SGNQF](Module gps-mod-SGNQF)
  • [Module : imu-mod-IFETI](Module imu-mod-IFETI)
  • [Module : imu-mod-IOISA](Module imu-mod-IOISA)
  • [Module : imu-mod-ISRAD](Module imu-mod-ISRAD)
  • [Module : imu-mod-SGNDN](Module imu-mod-SGNDN)
  • [Module : imu-mod-SGSFR](Module imu-mod-SGSFR)
  • [Module : imu-mod-AACEX](Module imu-mod-AACEX)
  • [Module : imu-mod-IFICR](Module imu-mod-IFICR)
  • [Module : imu-mod-IOBMA](Module imu-mod-IOBMA)

  Section : topology

  • [CSPS topology](CSPS topology)

  Section : query interface

  • [CSPS query interface](CSPS query interface)

  Section : Library usage

  • [Library usage](Library usage)

  Development : logs


Clone this wiki locally