3.1. General Presentation

3.1.1. Introduction

EGOS_advantages

3.1.1.1. Development Time:

In order to reduce the development time for an IoT application, EGOS provides the support of all kinds of drivers used in this domain: LoRa, Sigfox, IHM, ModBus, Accelerometer, GNSS, BLE, ... Each driver type is defined with some generic interfaces (for example: send a data in LoRa).

The EGOS architecture is built to provide a full hardware abstraction. At the application, knowing which chip is used looks obvious.

Some additional utility libraries are given, for example, for doing mathematics data management, calculating a position, handling time and string and so on. These algorithms enable the application to be set up faster than if each developer needs each time to repeat data's standard handling in IoT.

3.1.1.2. Safety

To ensure security and quality of EGOS, the software quality management is based on the V-Model. Egos is under version control to have a traceability of evolution. Documentation is written to validate a behaviour and the enhancement of the OS. To ensure that the new features or updates fit with EGOS, a continuous integration (CI) runs on GitLab. Each time that a modification is done on the project, the build of the project runs and can be integrated only if there is no error. In addition, strict coding rules are used and checked during the code review step done by the integrator. A static analysis is daily executed to check evolution.

The Kernel is only composed of ERTOSGENER owner's code. There are no open sources to ensure the Kernel control by ERTOSGENER.

EGOS' architecture is layered to ensure the independence of each part: the first part for which is Kernel specific (only accessible by ERTOSGENER), the second for which is hardware specific (accessible by contributors) and the third and last one for which is application specific. These three layers are cut again in sub-layers and so on. For example, the hardware layer is composed of a MCU, HAL and driver sub-layers and then the driver sub-layer is cut in communication and HMIsub-layers.

Fail-safe mechanisms are used to delete the crash of EGOS. For example, each time a pointer is used, its validity is checked. Some guardians contributes also to it by checking memory and stacks usages and execution.

This Kernel is based on an hybrid architecture. The user area does not access directly to Kernel services, it uses it through interfaces process and uses direct accesses only for utilities routines. It ensures safety and optimal performances in EGOS.

3.1.1.3. Community

To help EGOS to grow and to have a feedback of improvements, the project is based on a community to do contributions. The community can add its own development drivers and the support of new microcontrollers.

The community feedback and development are given through GitLab. It ensures an easy way to communicate between contributors and ERTOS' team but it is also a way check quality control before the integration in the project.

3.1.1.4. Modularity

EGOS wants to cover many use-cases but each application does not need to be full-feature (lack of memory, lack of hardware, lack of meaning, ...). The project provides a high modularity level for each area (Kernel, Contributor, User). This modularity makes the integration easier to fit to an IoT specific project. For example, if the LoRa network is not used an IoT project, it is easy to remove from EGOS.

Architecture

3.1.1.5. Independence

  • All the Kernel has been developed in France by ERTOSGENER and it maintains by its team.
  • Independence of data platforms (cloud)
  • Independence of board manufacturers
  • Independence of IoT manufacturers

3.1.1.6. Ease of Use

EGOS enables application development for companies which are not specialized in IoT and/or in embedded software development. It is provided by:

  • Generic user APIs
  • "Assisted" memory management
  • Utility's library
  • Power consumption management
  • Preconfigured behaviours
  • Macros to help development and reduce code duplication