Open Source AUTOSAR solutions

Arctic Core

Open Source AUTOSAR platform.
Download Arctic Core now!

Arctic Studio

Development IDE for Arctic Core and AUTOSAR.
Download Arctic Studio now!

Professional AUTOSAR solutions

Arctic Core Professional

Commercial license of Arctic Core AUTOSAR platform.

Arctic Bootloader

Arctic Core professional bootloader.

BSW Builder

Configuration of AUTOSAR basic software. Get trial!

RTE Builder

Generation of AUTOSAR runtime environment. Get trial!

Extract Builder

Easy creation of AUTOSAR ECUs. Get trial!

SWC Builder

Design of AUTOSAR software components. Get trial!

Posts Tagged ‘RTOS’

Scheduling strategies in an embedded RTOS environment

Saturday, 11 July, 2009

Most of today’s embedded real-time operating systems (RTOS) use the same scheduling method i.e. a priority based task switching algorithm. This means that the task with the highest priority that is ready to run is the one getting the CPU time. A more interesting aspect of scheduling is the strategies that are used to put the tasks into ready state. Two dominating techniques are used by RTOS of today’s embedded systems: time-triggered and event-triggered. Actually, the time-triggered strategy is a special case of the event-triggered strategy, but its heavy use within the automotive and control industry has categorized it as a strategy of its own.

Event-triggering is the most commonly used strategy in network applications. Most often an external event trigger a task to start executing, for instance when a PDU arrives an event triggers a router task to execute in order to define where the PDU should be sent. In automotive ECU:s this strategy is often used in gateway applications i.e. ECU:s that send CAN, LIN or Flexray packets between different networks in the car or truck.

In a time-triggered system it is the system clock that triggers the execution of a certain task. This type of execution is suitable for powertrain and control applications using regulators in its application loop, for instance fetching new samples from the ADC every 20 ms to get a good filtering algorithm. The time-triggered strategy can be combined with a deadline scheduling algorithm where the task with the earliest deadline gets to execute. A benefit of the time-triggered strategy is that all tasks execute in a scheme independent of external events. The consequence of this is that the CPU load is more or less constant, making profiling and load measurements easy to perform. This gives a more robust system design.

The two strategies described above can be combined to create a mixed system. The most common mix is to add time-triggered tasks to event-triggered systems since these systems often need to execute some tasks periodically, for example sending a heartbeat CAN-frame every 20 ms. Adding event-triggers to time-triggered systems are more rare since this kind of mixed system will loose the benefits of the stable CPU-load of a pure time-triggered system.

Benefits of a Statically Configured RTOS

Thursday, 2 July, 2009

Today’s embedded systems are getting larger and more complex for each new system design. This implies that a real time operating system (RTOS) should support hundreds of processes and memory sizes of many hundred of megabytes.

Although this gives the consumer better products with more functionality there are systems where dynamic behavior is not the desired one. In systems where timing and/or safety is the main requirement a dynamic behavior can be a total disaster. To design a good safety-critical system it is very important to be sure that the needed resources are available at the right time. For example the injection of fuel in a combustion engine must be exactly synchronized with the position of the piston to get perfect compression in the cylinder. The best way to design such a system is to allocate all the desired resources at design time rather than doing it during execution. This gives a worst case scenario from the beginning and there is no risk that the system is overloaded at a critical time.

When using a statically configured RTOS it is possible for the developer to analyze the characteristics of the system thanks to the static timing and resource allocation. To verify the design it should be possible to measure the actual execution time of the different processes and put this data inot a design tool and use the tool to verify that the behavior is the desired one.