Informacja

Drogi użytkowniku, aplikacja do prawidłowego działania wymaga obsługi JavaScript. Proszę włącz obsługę JavaScript w Twojej przeglądarce.

English (EN)·Polski (PL)·Yкраїнський (UK)
Przejdź do strony domowej biblioteki Centralna Biblioteka Wojskowa Link otwiera się w nowym oknie Logo biblioteki Prolib Integro - strona głównaCentralna Biblioteka Wojskowa

Wyszukujesz frazę "real-time operating system" wg kryterium: Temat

  Lista filtrów
Wyrównaj
    Wyświetlanie 1-2 z 2
    Tytuł:
    Real-Time Operating Systems for Robotic Applications : a Comparative Survey
    Autorzy:
    Kmiecik, P.
    Granosik, G.
    Powiązania:
    https://bibliotekanauki.pl/articles/385011.pdf
    Data publikacji:
    2015
    Wydawca:
    Sieć Badawcza Łukasiewicz - Przemysłowy Instytut Automatyki i Pomiarów
    Tematy:
    real-time operating system
    survey
    Opis:
    Modern robotics brings up a variety of new challenges. Industrial-only times are gone forever. Nowadays, by performing many diversified services, robots turned out to be a part of our everyday life. There is no doubt that they should be able to interact with this new miscellaneous environment seamlessly. Along with the number of requirements, the importance of software increases. While gaining more autonomy, besides standard motion control, a wide range of cogntive tasks has to be executed simultaneously. It is quite obvious that complex systems with a lot of independent modules and many functions to perform need flexible and reliable sofware solutions. This article takes a Real-Time Operating System as an answer to the problems of the new generation robotics.By comparing selected features, it provides an evaluation of the most popular commercial and non-commercial solutions. Paper describes the key characteristics that should be taken into consideration during the design process and presents several examples of their successful robotic applications, including our own choices for decentralized controllers.
    Źródło:
    Journal of Automation Mobile Robotics and Intelligent Systems; 2015, 9, 3; 9-17
    1897-8649
    2080-2145
    Pojawia się w:
    Journal of Automation Mobile Robotics and Intelligent Systems
    Dostawca treści:
    Biblioteka Nauki
    Artykuł
    Tytuł:
    Experience Report: Towards Extending an OSEK-Compliant RTOS with Mixed Criticality Support
    Autorzy:
    Gupta, T.
    Luit, E. J.
    van den Heuvel, M. M. H. P.
    Bril, R. J.
    Powiązania:
    https://bibliotekanauki.pl/articles/384148.pdf
    Data publikacji:
    2018
    Wydawca:
    Politechnika Wrocławska. Oficyna Wydawnicza Politechniki Wrocławskiej
    Tematy:
    OSEK
    RTOS
    mixed criticality
    real-time operating system
    Opis:
    Background: With an increase of the number of features in a vehicle, the computational requirements also increase, and vehicles may contain up to 100 Electronic Control Units (ECUs) to accommodate these requirements. For cost-effectiveness reasons, amongst others, it is considered desirable to limit the growth of, or preferably reduce, the number of ECUs. To that end, mixed criticality is a promising approach that received a lot of attention in the literature, primarily from a theoretical perspective. Aim: In this paper, we address mixed criticality from a practical perspective. Our prime goal is to extend an OSEK-compliant real-time operating system (RTOS) with mixed criticality support, enabling such support in the automotive domain. In addition, we aim at a system (i) supporting more than two criticality levels; (ii) with minimal overhead upon an increase of the so-called criticality level indicator of the system; (iii) requiring no changes to an underlying operating system; and (iv) featuring further extensions, such as hierarchical scheduling and multi-core. Method: We used the so-called adaptive mixed criticality (AMC) scheme as a starting point for mixed criticality. We extended that scheme from two to more than two criticality levels (satisfying (i)) and complemented it with specified behavior for criticality level changes. We baptized our extended scheme AMC*. Rather than selecting a specific OSEK-compliant RTOS, we selected ExSched, an operating system independent external CPU scheduler framework for real-time systems, which requires no modifications to the original operating system source code (satisfying (iii)) and features further extensions (satisfying (iv))). Results: Although we managed to build a functional prototype of our system, our experience with ExSched made us decide to rebuild the system with a specific OSEK-compliant RTOS, being µC/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements. Conclusions: Compared to extending ExSched with AMC*, extending µC/OS-II turned out to be straightforward. Although we now have a basic system operational and available for experimentation, enhancements of the AMC*-scheme are considered desirable before exploitation in a vehicle. Background: With an increase of the number of features in a vehicle, the computational requirements also increase, and vehicles may contain up to 100 Electronic Control Units (ECUs) to accommodate these requirements. For cost-effectiveness reasons, amongst others, it is considered desirable to limit the growth of, or preferably reduce, the number of ECUs. To that end, mixed criticality is a promising approach that received a lot of attention in the literature, primarily from a theoretical perspective. Aim: In this paper, we address mixed criticality from a practical perspective. Our prime goal is to extend an OSEK-compliant real-time operating system (RTOS) with mixed criticality support, enabling such support in the automotive domain. In addition, we aim at a system (i) supporting more than two criticality levels; (ii) with minimal overhead upon an increase of the so-called criticality level indicator of the system; (iii) requiring no changes to an underlying operating system; and (iv) featuring further extensions, such as hierarchical scheduling and multi-core. Method: We used the so-called adaptive mixed criticality (AMC) scheme as a starting point for mixed criticality. We extended that scheme from two to more than two criticality levels (satisfying (i)) and complemented it with specified behavior for criticality level changes. We baptized our extended scheme AMC*. Rather than selecting a specific OSEK-compliant RTOS, we selected ExSched, an operating system independent external CPU scheduler framework for real-time systems, which requires no modifications to the original operating system source code (satisfying (iii)) and features further extensions (satisfying (iv))). Results: Although we managed to build a functional prototype of our system, our experience with ExSched made us decide to rebuild the system with a specific OSEK-compliant RTOS, being µC/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements. Conclusions: Compared to extending ExSched with AMC*, extending µC/OS-II turned out to be straightforward. Although we now have a basic system operational and available for experimentation, enhancements of the AMC*-scheme are considered desirable before exploitation in a vehicle.
    Źródło:
    e-Informatica Software Engineering Journal; 2018, 12, 1; 305-320
    1897-7979
    Pojawia się w:
    e-Informatica Software Engineering Journal
    Dostawca treści:
    Biblioteka Nauki
    Artykuł
      Wyświetlanie 1-2 z 2

      Ta witryna wykorzystuje pliki cookies do przechowywania informacji na Twoim komputerze. Pliki cookies stosujemy w celu świadczenia usług na najwyższym poziomie, w tym w sposób dostosowany do indywidualnych potrzeb. Korzystanie z witryny bez zmiany ustawień dotyczących cookies oznacza, że będą one zamieszczane w Twoim komputerze. W każdym momencie możesz dokonać zmiany ustawień dotyczących cookies