DOCSLIB.ORG

Embedded O.S

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Embedded O.S Aknoledgement Form embedded O.S. to A special thanks Code Generation to Paolo Gai (Evidence S.r.l.) Mauro Marinoni [[email protected] ] for the sopport preparing this Retis Lab presentation. Scuola Superiore Sant' Anna 2 / 66 Objectives Embedded O.S. OSEK standard Part I Erika kernel Hardware platform FLEX board Demo addon board Embedded O.S. Scilab/Scicos Embedded Codegen Structure and implementation Examples 3 / 66 Why an embedded O.S. ? Why a Real -Time embedded O.S. ? It reduces the complexity of the An embedded applications tipically application; presents a lot of interactions with It increases the reusability of the code; the environment; It simplify the SW debugging; That requires a management of the It reduces the time to market: response time to an external event. ... 5 / 66 6 / 66 1 Developement scenario The footprint problem ... Typical scenario for an embedded system: Considering typical multiprogrammed environments: microcontroller (typically with reduced number instruction) a full -fledged POSIX footprint is around 1 Mb lack of resources (especially RAM!!!) use of profiles to support subset of the standard dedicated HW a profile is a subset of the full standard that lists a set of services typically used in a given environment dedicated interaction patterns POSIX real time profiles are specified by the ISO/IEEE a microwave oven is NOT a general purpose computer a microwave oven is NOT a general purpose computer standard 1003.13 The system we want to be able must fit on a typical These assumptions leads to different programming styles, system -on -chip memory footprint and to SW architectures different from general purpose computers . that is, around 10 Kb of code and around 1 Kb of RAM... 7 / 66 8 / 66 POSIX top -down approach SoC needs bottom -up approaches! POSIX defines a top -down approach towards we would like to have footprint in the order of 1 -10 Kb embedded systems API design the idea is to have a bottom -up approach the interface was widely accepted when the profiles starting from scratch, design came out a minimal system these profiles allow easy upgrades to more powerful that provides a minimal API systems that is able to efficiently describe embedded systems possibility to reuse previous knowledges and code with stringent temporal requirements with limited resources PSE51 systems around 50 -150 Kbytes Results : that size fits for many embedded devices, like single RTOS standards (OSEK -VDX, uITRON) board PCs 2 Kbytes typical footprint SHaRK is a PSE51 compliant system 2 Kbytes typical footprint 9 / 66 10 / 66 What is OSEK/VDX? Objectives It is a standard for an open -ended architecture for distributed control units in vehicles portability and reusability of the application The name: software OSEK : Offene Systeme und deren Schnittstellen für die Elektronik specification of abstract interfaces for RTOS and im Kraft -fahrzeug (Open systems and the corresponding interfaces for automotive electronics) network management VDX : Vehicle Distributed eXecutive (another french proposal of API similar to OSEK) specification independent from the HW /network OSEK/VDX is the interface resulted from the merge of the two details projects ( http://www.osek -vdx.org ) Motivations: scalability between different requirements to high, recurring expenses in the development and variant adapt to particular application needs management of non -application related aspects of control unit software. verification of functionality and implementation incompatibility of control units made by different manufacturers using a standardized certification process due to different interfaces and protocols. using a standardized certification process 11 / 66 12 / 66 2 Advantages System philosophy clear savings in costs and development time. standard interface ideal for automotive applications scalability scalability enhanced quality of the software using conformance classes creation of a market of uniform competitors configurable error checking independence from the implementation and portability of software the firmware on an automotive ECU is 10% RTOS and 90% drivers standardised interfacing features for control units Static is better: with different architectural designs everything is specified before the system runs intelligent usage of the hardware present on the static approach to system configuration no dynamic allocation on memory vehicle no dynamic creation of tasks for example, using a vehicle network the ABS controller no flexibility in the specification of the constraints could give a speed feedback to the powertrain custom languages that helps off -line configuration of the system microcontroller OIL : parameters specification (tasks, resources, stacks…) microcontroller KOIL : kernel aware debugging 13 / 66 14 / 66 Support for automotive requirements Application building process input the idea is to create a system that is RTOS configuration drivers configuration OIL DIL output reliable device drivers third part libraries templates with real -time predictability DIL Conf. Tool OIL support for Debugger Conf. Tool fixed priority scheduling with immediate priority ceiling non preemptive scheduling preemption thresholds RTOS configuration device drivers ORTI description binary image ROM execution of code C code C/ASM code KOIL .elf stack sharing (limited support for blocking primitives) documented system primitives Linker behavior objects application C/ASM objects performance of a given RTOS must be known .o objects C code Compiler .o RTOS library .o .a 15 / 66 16 / 66 OSEK/VDX standards Processing levels The OSEK/VDX consortium packs its standards the OSEK OS specification describes the in different documents processing levels that have to be supported by OSEK OS operating system an OSEK operating system OSEK Time time triggered operating system OSEK COM communication services OSEK FTCOM fault tolerant communication OSEK NM network management OSEK OIL kernel configuration OSEK ORTI kernel awareness for debuggers 17 / 66 18 / 66 3 Conformance classes Conformance classes There are four conformance classes OSEK OS should be scalable with the application needs There are four conformance classes BCC1 BCC1 different applications require different services basic tasks, one activation, one task per priority the system services are mapped in Conformance Classes BCC2 a conformance class is a subset of the OSEK OS standard BCC1 plus: > 1 activation, > 1 task per priority ECC1 objectives of the conformance classes BCC1 plus: extended tasks allow partial implementation of the standard ECC2 allow an upgrade path between classes ECC1 plus: > 1 activation (basic tasks), > 1 task per priority services that discriminates the different conformance classes multiple requests of task activations task types number of tasks per priority 19 / 66 20 / 66 Basic tasks Extended tasks a basic task is extended tasks can use events for synchronization a C function call that is executed in a proper context an event is simply an abstraction of a bit mask that can never block can lock resources events can be set/reset using appropriate primitives can only finish or be preempted by an higher priority task or IS R a task can wait for an event in event mask to be set a basic task is ideal for implementing a kernel -supported stack sharing, because extended tasks typically the task never blocks have its own stack when the function call ends, the task ends, and its local variab les are are activated once destroyed in other words, it uses a one -shot task model have as body an infinite loop over a WaitEvent() primitive support for multiple activations extended tasks do not support for multiple activations in BCC2, ECC2, basic tasks can store pending activations (a task can be ... but supports multiple pending events activated while it is still running) ... but supports multiple pending events 21 / 66 22 / 66 Scheduling algorithm Interrupt service routine the scheduling algorithm is fundamentally a OSEK OS directly addresses interrupt management in the standard API fixed priority scheduler interrupt service routines (ISR) can be of two types with immediate priority ceiling Category 1: without API calls simpler and faster, do not implement a with preemption threshold call to the scheduler at the end of the ISR Category 2: with API calls these ISR can call some primitives the approach allows the implementation of (ActivateTask, ...) that change the scheduling behavior. The end of the ISR is a rescheduling point preemptive scheduling ISR 1 has always a higher priority of ISR 2 non preemptive scheduling mixed finally, the OSEK standard has functions to directly manipulate the CPU interrupt status 23 / 66 24 / 66 4 Counters and alarms Application modes Counter OSEK OS supports the concept of is a memory location or a hardware resource used to count events application modes for example, a counter can count the number of timer an application mode is used to influence interrupts to implement a time reference the behavior of the device Alarm Alarm is a service used to process recurring events example of application modes an alarm can be cyclic or one shot normal operation when the alarm fires, a notification takes place debug mode task activation diagnostic mode call of a callback function set of an event ... 25 / 66 26 / 66 Hooks Error handling OSEK OS specifies a set of the OSEK OS has two types or error return values hooks that are
Load more

Recommended publications
  • Efficient Scheduling Library for Freertos
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2016 Efficient Scheduling Library for FreeRTOS ROBIN KASE KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY Efficient Scheduling Library for FreeRTOS ROBIN KASE Master’s Thesis at KTH Information and Communication Technology Supervisor: Kenji Kise (Tokyo Institute of Technology) Examiner: Johnny Öberg (KTH) TRITA-ICT-EX-2016:166 Abstract At present, there is a gap between practical implementations of task scheduling on numerous popular Real-Time Operating Systems (RTOSs) and theoretical real-time scheduling. It is difficult to choose what theoretical real-time scheduling concepts to implement when designing a kernel, as theoretical concepts grow and improve over time. Furthermore, the kernel can be kept simpler when offering only simple fixed priority scheduling policy, as advanced scheduling features often require more com- plex implementation and larger overhead. By offering a real-time scheduling library implemented in user space, the user can choose whether to skip the overhead, or use more advanced theories. At the moment there exists already several scheduling frameworks for FreeRTOS. However, they are either difficult to use, not completely implemented in user space, or not providing various theoretical scheduling policies. An open source scheduling library for FreeRTOS implemented in user space that is user friendly and runs with low overhead, Efficient Scheduling Library (ESFree) is proposed. The proposed scheduling library provides polling server that runs aperiodic and sporadic jobs, dependable timing error detection and handling, Rate-Monotonic Scheduling (RMS), Deadline-Monotonic Scheduling (DMS) and Earliest Deadline First (EDF) scheduling policies to provide theoretical real-time scheduling features to speed up development of complex projects, and make FreeRTOS friendlier to students who have newly studied real-time scheduling.
    [Show full text]
  • Download The
    ERIKA Enterprise Current limitations and possible solutions Version: 7 February 11, 2016 DRAFT About Evidence S.r.l. Evidence is a company operating in the field of software for embedded real-time systems. It started in 2002 as a spin-off company of the Real-Time Systems (ReTiS) Lab of the Scuola Superiore Sant'Anna (Pisa, Italy). Today, Evidence is a dynamic company having collaborations in the field of electronics, telecommunications, automotives, and industrial automation. People at Evidence are experts in the domain of embedded and real-time systems, with a deep knowledge on the design and specification flow of embedded software, especially for the embedded market. Besides providing consultancy services, Evidence also provides: BSPs based on Linux for embedded devices, evaluation boards featuring most innovative 8, 16 and 32-bit microcontrollers for the embedded market, development tools for making embedded software development easier, and tools for the schedulability analysis of real-time tasks running on your final product. For more information see: http://www.evidence.eu.com Contact Info Evidence Srl, Via Carducci 56 Localit`aGhezzano 56010 S.Giuliano Terme PISA Italy Tel: +39 050 99 11 224 Fax: +39 050 99 10 812 For more information about Evidence products, please send an e-mail to the follow- ing address: [email protected]. Other information about the Evidence product line can be found at the Evidence web site at: http://www.evidence.eu.com. This document is Copyright 2011-2015 Evidence S.r.l. Information and images contained within this document are copyright and the property of Evidence S.r.l.
    [Show full text]
  • A Fully Open-Source Platform for Automotive Systems
    A fully Open-Source Platform for Automotive Systems Implementation by Paolo Gai, CEO Evidence Srl Bruno Morelli, Evidence Srl 2 The company Founded in 2002, we do custom design and development of software for small embedded devices ~20 qualified people with an average age of 34 years, 30% PhD Experience in automotive, industrial, white goods RTOS and MCU skills • OSEK/VDX, AUTOSAR, • Automatic code generation Embedded Linux skills • 8 Yrs experience in custom BSPs, U-Boot, kernel drivers, • Initial developers of the SCHED_DEADLINE patch 3 Everything in one slide • We created a completely Open-source solution for Automotive systems + • Linux for HMI, communication and logging • ERIKA Enterprise for real-time performance and control • We will show a demo on a dual core Freescale iMX6 • http://erika.tuxfamily.org • Free RTOS for automotive devices • Open-source license , static linking of closed source code • ERIKA Enterprise is the first and only OSEK/VDX certified open-source RTOS 4 Agenda • IVI system requirements and multicore devices • Main features of Erika Enterprise • Success stories • Towards a fully integrated Open-Source solution with Linux and Erika Enterprise • (some) implementation details • Demo on Freescale iMX6 5 Main Requirements of future IVI systems • Fast Boot • there must be a subsystem ready to go in a few ms • Linux boot times are usually in the order of seconds • Real-Time support • there must be a subsystem with real-time performance • e.g. CAN Bus, motor control • Quality of Service • IVI applications need soft-realtime
    [Show full text]
  • ERIKA Enterprise Basic Manual
    ERIKA Enterprise Basic Manual ...multithreading on a thumb! version: 1.1.2 July 18, 2008 About Evidence S.r.l. Evidence is a spin-off company of the ReTiS Lab of the Scuola Superiore S. Anna, Pisa, Italy. We are experts in the domain of embedded and real-time systems with a deep knowledge of the design and specification of embedded SW. We keep providing signifi- cant advances in the state of the art of real-time analysis and multiprocessor scheduling. Our methodologies and tools aim at bringing innovative solutions for next-generation embedded systems architectures and designs, such as multiprocessor-on-a-chip, recon- figurable hardware, dynamic scheduling and much more! Contact Info Address: Evidence Srl, c/o Incubatore Pont-Tech Viale Rinaldo Piaggio, 32 56025 Pontedera (PI), Italy Tel: +39 0587 274 823 Fax: +39 0587 291 904 For more information on Evidence Products, please send an e-mail to the following address: [email protected]. Other informations about the Evidence product line can be found at the Evidence web site at: http://www.evidence.eu.com. This document is Copyright 2005-2008 Evidence S.r.l. Information and images contained within this document are copyright and the property of Evidence S.r.l. All trademarks are hereby acknowledged to be the properties of their respective owners. The information, text and graphics contained in this document are provided for information purposes only by Evidence S.r.l. Evidence S.r.l. does not warrant the accuracy, or completeness of the information, text, and other items contained in this document.
    [Show full text]
  • Embedded Operating Systems
    7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments.
    [Show full text]
  • Wireless Sensor Network (WSN)
    Catherine Greene Chloe Norris CREU 2010-2011 Wireless Sensor Network (WSN) Detects Uses Temperature Industrial process & Sound monitoring Vibrations Machine monitoring Pressure Monitoring the Motion environment Pollutants Healthcare Home automation Traffic control Source: http://en.wikipedia.org/wiki/Wireless_sensor_network Nodes What it consists of Prices Can have more than one Varies sensor Size Usually has a radio Complexity transceiver A more complex sensor For wireless could be a few hundred communication A less intricate one Small microcontroller could be fairly cheap Energy source Ex: battery Source: http://en.wikipedia.org/wiki/Wireless_sensor_network How they work Sensors support a multi-hop routing algorithm nodes function as forwarders Relay data packets to a base station (known as a wireless ad-hoc network) Think of a sensor like a computer Source: http://en.wikipedia.org/wiki/Wireless_sensor_network Applications Area Monitoring WSN would be put in an area where something is being monitored Ex: a country at war with another may place nodes over a battlefield to detect enemy intrusion, sensors would detect heat, pressure, sound, light, electro-magnetic fields, vibrations, etc… If a sensor went off it would report it to a base station (message might be sent through internet or satellite) Ex: detecting vehicles Source: http://en.wikipedia.org/wiki/Wireless_sensor_network Applications Environmental Monitoring Similar to area monitoring Ex (pictured): state of permafrost in the Swiss Alps
    [Show full text]
  • Paralel Gerçek Zamanli Kiyaslama Uygulama Takimi
    T.C. SAKARYA ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ PARALEL GERÇEK ZAMANLI KIYASLAMA UYGULAMA TAKIMI YÜKSEK LİSANS TEZİ Sevil SERTTAŞ Enstitü Anabilim Dalı : BİLGİSAYAR VE BİLİŞİM MÜHENDİSLİĞİ Tez Danışmanı : Dr. Öğr. Üyesi Veysel Harun ŞAHİN Nisan 2019 TEŞEKKÜR Yüksek lisans eğitimim boyunca değerli bilgi ve deneyimlerinden yararlandığım, araştırmanın planlanmasından yazılmasına kadar tüm aşamalarında yardımlarını esirgemeyen değerli danışman hocam Dr. Öğr. Üyesi Veysel Harun ŞAHİN’e teşekkürlerimi sunarım. i İÇİNDEKİLER TEŞEKKÜR ........................................................................................................... i İÇİNDEKİLER ...................................................................................................... ii SİMGELER VE KISALTMALAR LİSTESİ ....................................................... iv ŞEKİLLER LİSTESİ ............................................................................................. v TABLOLAR LİSTESİ ........................................................................................... vi ÖZET ..................................................................................................................... vii SUMMARY ........................................................................................................... viii BÖLÜM 1. GİRİŞ …………………………………………………………….................................... 1 BÖLÜM 2. WCET .................................................................................................................... 3 BÖLÜM 3. KIYASLAMA UYGULAMALARI
    [Show full text]
  • COMPARATIVE ANALYSIS of DIFFERENT OPERATING SYSTEMS USED for LOW-END IOT DEVICES 1ZURABIA RIAZ 1University of Management and Technology, Lahore, Pakistan
    VFAST Transactions on Software Engineering http://vfast.org/journals/index.php/VTSE@ 2020 ISSN(e): 2309-3978;ISSN(p): 2411-6246 Volume 8, Number 1, January-December, 2020 pp. 64-72 COMPARATIVE ANALYSIS OF DIFFERENT OPERATING SYSTEMS USED FOR LOW-END IOT DEVICES 1ZURABIA RIAZ 1University of Management and Technology, Lahore, Pakistan. [email protected] Abstract-Internet of Things is the new emerging field projected to interconnect billions of devise through the internet. IoT devices divided into high end as well as low end devices. Linux based operating systems can easily handle IoT based high end devices and due to resource based constraints that includes very less memory, energy power for computation of low end IoT devices makes it difficult to develop. In this paper the main focus is on the detail discussions of the operating systems that will satisfy the requirements of IoT devices for low end categories. Comparative analysis will be performed for different operating system and then the by keeping the focus on the OS which are close to Linux and are fit for the low end IoT devices. Keywords: Internet of Things, Low End Devices, embedded systems 1. Introduction:. Internet of Things or IoT can be root as the availability of excessive and multiple devices (things) interconnected with embedded devices to send and receive data via Internet.For communication different standards for communicating protocols at network layer in-combination with IPv6 has been developed. These protocols as a result enable the heterogeneous devices to connect through internet. In context with hardware, IoT is a collected combination of hardware devices which are heterogeneous in nature.
    [Show full text]
  • Tcc Engenharia Eletrica
    UNIVERSIDADE DO SUL DE SANTA CATARINA MAX BACK SISTEMA EMBARCADO COM RTOS: UMA ABORDAGEM PRÁTICA E VOLTADA A PORTABILIDADE Palhoça 2018 MAX BACK SISTEMA EMBARCADO COM RTOS: UMA ABORDAGEM PRÁTICA E VOLTADA A PORTABILIDADE Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia Elétrica com ênfase em Telemática da Universidade do Sul de Santa Catarina como requisito parcial à obtenção do título de Engenheiro Eletricista. Orientador: Prof. Djan de Almeida do Rosário, Esp. Eng. Palhoça 2018 Dedico este trabalho а Deus, por ser o verdadeiro princípio e fim de todas as coisas (das que valem a pena). AGRADECIMENTOS Agradeço a minha esposa Gizele e meus filhos, Eric e Thomas, meus pais e a toda minha família que, com muito carinho е apoio, não mediram esforços para que eu chegasse até esta etapa de minha vida. Agradeço aos professores do curso por terem transmitido seu conhecimento a mim e meus colegas com tanto empenho e dedicação. Não existe triunfo sem perda, não há vitória sem sofrimento, não há liberdade sem sacrifício. (O Senhor dos Anéis – J.R.R. Tolkien, 1954) RESUMO A crescente demanda pelo desenvolvimento de solução conectadas entre sistemas já existentes, assim como a ampliação do uso destes sistemas embarcados mostram a importância de soluções robustas, de tempo real, com ciclos de desenvolvimento cada vez mais curtos e necessidade de reaproveitamento de código. Este trabalho apresenta a seleção do sistema operacional de tempo real FreeRTOS e o experimento de sua utilização como base para o desenvolvimento de um controlador wearable (vestível) em duas plataformas de hardware diferentes, implementando a solução inicialmente em uma delas e depois portando para a outra plataforma, desenvolvendo principalmente a programação específica do novo hardware e procurando manter a parte da aplicação inalterada e independente de plataforma.
    [Show full text]
  • Designing High Throughput Routing Protocol for Wireless Body Area Networks
    International Journal of Technical Research and Applications e-ISSN: 2320-8163, www.ijtra.com Volume 6, Issue 2 (MARCH-APRIL 2018), PP. 85-91 DESIGNING HIGH THROUGHPUT ROUTING PROTOCOL FOR WIRELESS BODY AREA NETWORKS Noor khateeb Ali Khan 1, Shashank Singh 2, Department Of Computer Science Engineering Integral University Lucknow, India Abstract—Wireless Body Area Network (WBAN) is new emerging sub-field of WSN. A key application of Wireless Body A. BAN Positioning Area Network is health monitoring. Wireless sensors are placed BAN is described as a short-range, low-powered device on the human body or implanted in the body to monitor vital that operates around the human body (not limited to humans) signs like blood pressure, body temperature, heart rate, glucose providing a variety of applications. These applications may level etc. Use of Wireless Body Area Network technology to include medical, personal entertainment and consumer monitor health parameters significantly reduces the expenditures electronics. BANs can be described as special WSNs that have of patient in hospital. Wireless Body Area Sensors are used to monitor human health with limited energy resources. Different lesser nodes and much reliable with special importance placed energy efficient routing schemes are used to forward data from on QoS as compared to the tradition WSN. BAN in some cases body sensors to medical server. It is important that sensed data is referred to as BSN. of patient reliably received to medical specialist for further The positioning of BAN in relation with other wireless analysis. To minimize energy consumption and to increase the networks is shown in figure 1.
    [Show full text]
  • ERIKA Enterprise Minimal API Manual
    ERIKA Enterprise Minimal API Manual ...multithreading on a thumb! version: 1.1.3 December 11, 2012 About Evidence S.r.l. Evidence is a spin-off company of the ReTiS Lab of the Scuola Superiore S. Anna, Pisa, Italy. We are experts in the domain of embedded and real-time systems with a deep knowledge of the design and specification of embedded SW. We keep providing signifi- cant advances in the state of the art of real-time analysis and multiprocessor scheduling. Our methodologies and tools aim at bringing innovative solutions for next-generation embedded systems architectures and designs, such as multiprocessor-on-a-chip, recon- figurable hardware, dynamic scheduling and much more! Contact Info Address: Evidence Srl, Via Carducci 56 Localit`aGhezzano 56010 S.Giuliano Terme Pisa - Italy Tel: +39 050 991 1122, +39 050 991 1224 Fax: +39 050 991 0812, +39 050 991 0855 For more information on Evidence Products, please send an e-mail to the following address: [email protected]. Other informations about the Evidence product line can be found at the Evidence web site at: http://www.evidence.eu.com. This document is Copyright 2005-2012 Evidence S.r.l. Information and images contained within this document are copyright and the property of Evidence S.r.l. All trademarks are hereby acknowledged to be the properties of their respective owners. The information, text and graphics contained in this document are provided for information purposes only by Evidence S.r.l. Evidence S.r.l. does not warrant the accuracy, or completeness of the information, text, and other items contained in this document.
    [Show full text]
  • Levels of Specialization in Real-Time Operating Systems
    Levels of Specialization in Real-Time Operating Systems Björn Fiedler, Gerion Entrup, Christian Dietrich, Daniel Lohmann Leibniz Universität Hannover {fiedler, entrup, dietrich, lohmann}@sra.uni-hannover.de Abstract—System software, such as the RTOS, provides no robustness, security and so on; it increases the safety margins or business value on its own. Its utility and sole purpose is to serve makes it possible to cut per-unit-costs by switching to a cheaper an application by fulfilling the software’s functional and nonfunc- hardware. For price-sensitive domains of mass production, such tional requirements as efficiently as possible on the employed as automotive, this is of high importance [8]. hardware. As a consequence, every RTOS today provides some means of (static) specialization and tailoring, which also has a Intuitively, any kind of specialization requires knowledge long tradition in the general field of system software. about the actual application: The more we know, the better However, the achievable depth of specialization, the resulting we can specialize. In the domain of real-time systems (RTSs), benefits, but also the complexity to reach them differ a lot we typically know a lot about our application and its exe- among systems. In the paper, we provide and discuss a taxonomy cution semantics on the employed RTOS: To achieve real- for (increasing) levels of specialization as offered by (real-time) time properties, all resources need to be bounded and are system software today and in the future. We argue that system software should be specialized as far as possible – which is scheduled deterministically. Timing analysis depends on the always more than you think – but also discuss the obstacles that exact specification of inputs and outputs, including their inter- hinder specialization in practice.
    [Show full text]