Another tool has been developed; this tool verifies the runtime behavior of RTEMS applications. At a later stage, the RTEMS Center has started the RTEMS Improvement project which aims to create an adapted version of RTEMS (4.8.0) that will help facilitate the qualification process for RTEMS applications in space missions. Since the RTEMS Improvement project does not have the necessary hardware support, the main goal is to facilitate the process of qualifying applications that work with RTEMS, through: an RTEMS Tailored version, with the necessary modifications to correct the detected errors; an RTEMS Test Suite, to test RTEMS Tailored; and accompanying documentation (requirements document, design document, configuration document, user manual, etc.).
In a later phase of the RTEMS improvement project, when all the previous tasks for the RTEMS custom version have been added, it will be developed an RTEMS memory management module for the LEON3 class processors.
INTRODUCTION
- M OTIVATION
- O BJECTIVES
- I NSTITUTIONAL INTEGRATION
- P UBLICATIONS
- D OCUMENT ORGANIZATION
Another goal for the RTEMS improvement project is to produce an RTEMS memory management module for SPARC V8, LEON 3, processors. The RTEMS version 4.8.0, which is the version adopted for the development of the RTEMS enhancement project, does not provide a memory management module.
RTEMS OVERVIEW
RTEMS M ANAGERS
- Initialization Manager
- Task Manager
- Interrupt Manager
- Clock Manager
- Timer Manager
- Semaphore Manager
- Message Queue Manager
- Event Manager
- Barrier Manager
- Signal Manager
- Partition Manager
- Region Manager
- Dual-Ported Memory Manager
- I/O Manager
- Fatal Error Manager
- Rate Monotonic Manager
- User Extensions Manager
- Multiprocessing Manager
- Stack Bounds Checker
- CPU Usage Statistics
The Initialization Manager is called by the BSP in the System Initialization phase and is responsible for initializing and shutting down the remaining RTEMS and RTEMS Core managers. The Task Manager is responsible for managing RTEMS tasks (in Linux nomenclature RTEMS tasks are referred to as threads). The message queue manager is responsible for synchronization and communication between tasks by passing messages from one task to another.
The Event Manager is responsible for synchronization between tasks by triggering events from one task to another. The Barrier Manager is responsible for synchronizing a set of multiple tasks simultaneously, i.e. The Dual-Ported Manager is responsible for converting address representations between internal and external dual-ported memory areas.
The I/O manager is responsible for routing application calls (such as a read or write operation) to the selected driver. The User Extensions Manager is responsible for invoking user-specified functions at specific scheduling points, such as task creation, task submission, fatal error, etc. The CPU Usage Statistics Manager is responsible for determining the total execution time and CPU percentage for each task.
S UMMARY
The Rate Monotonic Manager is responsible for making jobs periodic, that is, producing periodic jobs to be scheduled according to the rate monotonic scheduling analysis. The functions specified on these extensions are called in the reverse order they were installed, LIFO8 order, and they are called before the default RTEMS function. Determining the stack usage is performed at each context switch and the time to perform this operation is currently proportional to the stack size.
This is not useful in a planning analysis for hard real-time systems because the worst case is not taken into account. Due to the fact that RTEMS integrates several features such as network protocols, file system support, multitasking support, interrupt management, inter-task communication, and inter-task synchronization, the basic RTEMS core is highly configurable. This chapter also provides a brief explanation for some of the RTEMS managers, such as the Initialization Manager; Job listing; Interrupt Manager; Watch Manager;.
RTEMS SUITE TAILORING
- RTEMS M ANAGERS U TILIZATION S URVEY
- RTEMS M ANAGERS E VALUATION
- RTEMS T AILORING P LAN
- Dead Code Removal
- Create Test Suite
- Find and Fix bugs
- Customize RTEMS
- Customize Test Suite
- RTEMS T AILORING W ORKFLOW
- RTEMS I MPROVEMENT O VERVIEW
- S UMMARY
Task Manager – This manager is required for multitasking and is one of the essential requirements of the customized version of RTEMS. The team decided not to include this manager, keeping it out of the scope of the RTEMS improvement. CPU Usage Statistics - Since the firmware will not use this feature, this manager is outside the scope of the RTEMS Improvement project.
This test suite has all the features and covers all the requirements for the RTEMS improvement project. The first version of the test suite was designed to meet the requirements of the RTEMS Improvement Project and test the minimum RTEMS. Since the minimum RTEMS has been changed in the RTEMS customization process, the test suite must also test and cover the changed features.
Consequently, only a subset of the Test Suite will also be produced, the necessary tests to ensure the correct operation of the RTEMS. With the original RTEMS software and the RTEMS patches it will be possible to generate a version of the RTEMS mate software. The next step is to configure the RTEMS and Test Suite for the space mission.
RTEMS FACILITATION OF QUALIFICATION
- G ALILEO S OFTWARE STANDARDS
- SW-DAL B FACILITATION OF QUALIFICATION
- GNU GCOV brief explanation
- GNU GCOV on RTEMS
- RTEMS REVERSE ENGINEERING
- RTEMS D OCUMENTATION
- T EST S UITE D ESIGN
- T EST S UITE I MPLEMENTATION
- T EST S UITE E XECUTION
- S EMAPHORE WITH P RIORITY I NHERITANCE /C EILING PROTOCOL BUG
- RTEMS T AILORED AND T EST S UITE E XECUTION
- S UMMARY
For the RTEMS Tailorable version, the final product of the RTEMS improvement project, the Galileo SW-DAL Level B was adopted. The left side of Figure 10 shows the libgcov part compiled with the application going to the target . This careful analysis is necessary to understand the main idea of the RTEMS improvement project.
An in-depth review of the source code was made during this phase of the project. Some of the bugs found are related to semaphores, as described in the Test Suite Execution section. The first step of the RTEMS Improvement Project was to generate the documentation that will serve as the basis for the RTEMS Improvement Project.
The doxygen was also used to help generate the software design document (SDD). The majority of the tests were implemented in a driver manner, as expressed in the previous section. The produced test suite for the RTEMS enhancement project was run in all the target processor defined in the project, plus the UNIX BSP.
For the priority legacy protocol, it must be demoted to the highest priority. In this chapter we have described the steps towards the RTEMS Qualifying process.
MEMORY MANAGEMENT
- M EMORY M ANAGEMENT MODULE
- Memory used by the application
- RTEMS Memory Protection
- Memory Management and Protection Models
- H ARDWARE M EMORY M ANAGEMENT U NIT
- H ARDWARE MMU SUPPORT
- Address Translation
- Memory protection
- RTEMS I MPROVEMENT M EMORY M ANAGEMENT M ODULE
- S UMMARY
The execution of the tests mentioned above showed that by incrementing or decrementing the value of a pointer, changing the memory where it points, reading, writing (changing, erasing or writing wrong data) any memory address, including the memory owned by task A. 23 A pointer is a variable that references the contents of another variable, basically a pointer contains the memory address of the variable it points to. The problems caused by this unwanted access depend on the importance of the task in which the data was modified.
The paging model consists of dividing memory into small pieces of the same size, called pages. When an application requests access to a specific memory address, instead the application accesses it directly, the access must first verify whether the address belongs to the application's memory segment, what type of access the application is trying to make, whether it is a Read /write, read-only or write-only, the type of access depends on the level of memory protection. PPN Physical Page Number - the high-order 24 bits of the 36-bit physical page address.
Since the RTEMS Improvement project, due to the use of standards such as MISRA-C and Galileo SW-DAL B, will not use dynamic memory allocation, although the memory allocation has deterministic time, the main purpose of the memory management module that will be developed in the scope of the RTEMS Improvement project will be for memory protection. When the phase of the Memory Management module starts, the main activities of the RTEMS enhancement will change, and Figure 7 will remain as shown in Figure 20. The chapter also indicates how RTEMS calculates the memory that will be used by the application, and ends with set out a possible vision for the implementation of the memory model that will be produced by the RTEMS Improvement project and the changes to the RTEMS Improvement development plan when the development of the Memory Management module starts.
CONCLUSION
RTEMS (Real Time Executive for Multiprocessor Systems) é um sistema operacional de tempo real de código aberto projetado e desenvolvido para ser competitivo com sistemas comerciais similares. Pensando nisso, foi criado um centro de pesquisa, o Edisoft RTEMS Centre, em colaboração com a Agência Espacial Europeia (ESA) sobre o sistema operacional RTEMS, com o objetivo de ajudar a comunidade espacial europeia a utilizar este sistema operacional. As atividades iniciais da equipe de desenvolvimento do RTEMS Center consistiam na criação de ferramentas de suporte e assistência na configuração e compilação do sistema operacional RTEMS.
Numa fase mais avançada do RTEMS Center, foi iniciado o projeto RTEMS Improvement, que visa disponibilizar uma versão do sistema operativo RTEMS, esta versão visa facilitar a qualificação das aplicações e está otimizada para trabalhar com processadores SPARC. família, nomeadamente processadores ERC32, LEON2 e LEON3 para a sua utilização em aplicações espaciais. Para produzir a versão adaptada ou fixa do sistema operacional RTEMS, é necessário seguir algumas regras tanto para a produção da documentação quanto para a correção e modificação do próprio código-fonte. Este desenvolvimento numa fase mais avançada deve-se ao facto deste módulo ser um objetivo secundário do projeto, lembrando que o objetivo principal do projeto é facilitar a qualificação de aplicações baseadas no sistema operativo RTEMS para o espaço.
A missão do projeto RTEMS Improvement é apresentar uma versão customizada do sistema operacional RTEMS, a versão RTEMS Tailored, que segue os padrões de software Galileo (GSWS [RD1]) no Nível B, SW-DAL B, e responde aos mais requisitos rigorosos apresentados. para o desenvolvimento de aplicações para sistemas de tempo real e de missão crítica. RD7] Silva, H., Apresentação Final e Relatório Final do RTEMS CENTER, ESTEC (Centro Europeu de Investigação e Tecnologia Espacial), Noordwijk - Holanda (2008). RD8] Site do RTEMS CENTER: http://rtemscentre.edisoft.pt [RD9] Site do RTEMS: http://www.rtems.com.
