Section: New Software and Platforms

PEGASE

Participants : Vincent Le Cam, Mathieu Le Pen, Laurent Mevel, Michael Doehler.

I4S is actually finalizing the setup of a new platform named PEGASE $2.0$ as the technological successor of the previous PEGASE platform developed by IFSTTAR.

The new version of PEGASE keeps the best of its previous version in its main vocation, to be a generic high level Wireless Sensor Platofrm.

• What does not change between PEGASE 1 and $2.0$: Based on various feedback from application fields, results from real structures monitored by PEGASE, and due to the rapid obsolescence of electronic devices, the design of the new PEGASE platform has been launched in 2013. Some of the main functions of PEGASE does not change but are reinforced.

  • Software genericity: use of a Linux embedded OS to make any application developed independently from the hardware, to make the user able to manage the system without ant physical and heavy operations.

  • Hardware genericity: with a principle of daughter and mother boards, each redundant need is embedded (processing, memory, timing, GPS, energy, etc) which each pluggable daughter board implements a specific function (sensing, 3G, Ethernet, communication, signal processing and relay control).

  • Accurate time synchronization: based on an original GPS and PPS algorithm, PEGASE platform is one of the only board able to time-stamp data from sensors or any event with an accuracy of some micro-seconds Universal Time.

• What's new on PEGASE 2 platform ?

  Previous principles are maintained or extended. Full electronic design from scratch occurred in 2014 to maximise its capacities in terms efficiency, cost, energy consumption, etc. Its main characteristics are

  • Important software evolutions: the platform embedded a real Linux kernel (not $\mu$Clinux as previously done for memory size questions). This new kernel allows the perception of PEGASE 2 as real PC (without screen and mouse) providing important functions as MMU, software upgrade.

  • Important hardware evolutions and integration

    • A very advanced GPS module (Ublox Neo 6T) to allow more accurate time synchronization (up to 100 nanoseconds)

    • An embedded energy harvesting module (and not from a daughter board as previously done) to recover energy from DC sources if available or a solar cell, while managing the low of dis/charging Lithium-Ion battery and the MMPT algorithms

  • A Single Development Kit (SDK) fully (re) coded in C++ (and not C-object as proposed before) that permit a real capitalization of software developments and knowledges implemented (such as algorithms for SHM). Based on an UML model

• A major evolution in PEGASE concept consists in providing a generic web-tool to monitor PEGASE platform (whatever is the version) and many others wireless and commercial devices. A reproach addressed to previous concept resides in the fact that PEGASE was too focused on providing a generic wireless platform. But a quite big work was still necessary to monitor the devices. This new concept has been already sold to companies (such as SNCF or Cofiroute) and allows:

  • To create one independent instance of the Supervisor by client

  • Each instance of the Supervisor works $100\%$ in the cloud with a secured access (https + login/password). Thus final users can operate it from anywhere in the world : at instrumented site level as at desk or during travel, etc.

  • For each client, the possibility to create an infinity of instrumentation projects

  • For each instrumentation project, to associate as many sensors as required by the application. Sensors can be PEGASE 1 or PEGASE 2 boards as many others : Labjack devices, some National Instruments acquisition boards, Meteo-France sources...

  The list of the devices known by the Supervisor is open and is supposed, year after year, to be completed. Thus, next PEGASE projects aims at providing not only some wireless sensors platform but also a modern, full-clouded, monitoring application. Moreover the 2015 $R\&D$ program plans to add a very interesting function from the scientific point of view: a Matlab plug-in. The idea consists in linking the data flow managed by supervisor directly and automatically to some Matlab sources codes uploaded on the web platform. The Supervisor will compile the original Matlab files. They are dynamically compiled on an embedded Matlab runtime library on the cloud server. Thus, once the the specifications about data format are written and took into account by developers, scientist can dynamically test and operate its Matlab models uploaded on the Supervisor.