Technologies - Sailsys


Sailsys is a software application that performs the tasks of data acquisition, light real time data processing and data logging. The functionality of a Sailsys application is described in one or more setup files that are loaded during the application start up. The user describes the system he wants to implement in the setup file using Sailsys simple scripting language. In fact a Sailsys that is started with no setup file or an empty one has almost no functionality.

Sailsys' design is component based. A component is a small piece of software that is designed to solve a very specific task; an example of component would be a GPS nmea frame decoder or a math formula like the addition of two floats. As the components only solve small problems, a single component by itself does not do much. Components then interact with each other to build a specific solution. Sailsys' scripting language is used to create the all the required components, to setup the components with specific working data (as polars data, settings, etc) and to establish the relationship between components so they can collaborate between them to implement a specific solution.

The scripting language commands can be executed at any time in the system as the scripting engine is always available. This opens a new set of system interaction possibilities and diagnostics as the system's setup can be altered live either locally or remotely.

Sailsys is delivered with a rich set of components already included. Those components support the most commonly used functionality:

  • Raw hardware acquisition from: analog inputs, pulse inputs, serial inputs, CAN inputs, Serial Ethernet servers, Racing Bravo Modules, DCell Matracan devices, etc.
  • Serial decoders: Nmea, XSens mti, MicroStrain 3DM, Octans, Phins, Dfw, FastNet, etc.
  • RBSP protocol: A TCP/UDP or serial protocol that allows interaction with expedition and end user custom software applications.
  • Data base and file logging
  • An extensive Math library that includes functionality for Polars, 1D and 2D interpolation, filtering, trigonometric, vectors, etc
  • Voice support: It enables the creation of customized voice messages that can be output using RBOnDeck on a windows platform.
  • Alarm monitor system: Monitors that chosen parameter values are within established ranges and send a warning when out.
  • ExpertSystem: The system allows acting on itself to react to certain user defined specified conditions.

With the large set of existing functionality it is possible to design quite a large number of solutions by describing the system using the scripting language and the setup files. If some specific customer feature cannot be achieved using existing functionality (as interfacing with a new sensor) it can be added using Bravo Systems custom engineering service.

Usually the new feature will be developed as a new component. As the new development is isolated from the other components, its development is easy and fast. Once developed as many instances of it can be created and debugging is easy as it only affects that component. Usually the development is small, hence the components created are normally small too. As functionality can be added in a modular and isolated way the impact of new developments is small, and testing and development tends to be safer than traditional monolithic development. In addition, as components are designed to be of as generic a purpose as possible, it is easy to reuse them, and this reduces the amount of changes needed for new developments.

For example: If we add support for a Compas decoder protocol like XSens mti with the scripting language it will be possible to define how many sensors of this type are necessary, specify what port they should attach to, if it is local or remote, etc...No modification of the binary is necessary.

On top of that Sailsys has been designed to exchange information with another instance of Sailsys, either running on the same machine or on a different machine. This is achieved using the RBSP protocol that can be attached to a serial, TCP or UDP port. This adds an extra level of flexibility that leaves open the choice of the architecture of the solution to the end user. As a result of this freedom the functionality of a setup file could be split in two or more sailsys running in two or more machines for example. Why would this be useful? Well there are many scenarios where that can be desirable. Some examples:

  • The calculation/processing load on a processor is so high that you choose to have a second computer to unload the main processor.
  • The user wants a racing processor where the features are final and not changed much, and a second processor to put experimental code.
  • The user wants a decentralized installation, so uses two processors placed in different locations to which he wires the necessary sensors.

Although the user can interact with Sailsys using its built-in shell prompt, usually Sailsys runs in the background as a service and the user interacts with it remotely using a network TCP connection and BravoOnDeck.