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 ‘embedded’

AUTOSAR Developers, Hardware Manufacturers and Embedded System Enthusiasts all Benefit from Arctic Core

Sunday, 30 August, 2009

Thanks to the open source license, Arctic Core can be used by anyone for commercial as well as non-commercial purposes. Following is a proposal of how to benefit from Arctic Core if you are an embedded application developer, a hardware manufacturer, an embedded system enthusiast or a company that wants to promote products.

  • The embedded application developer: Arctic Core is a flexible and powerful platform built according to the AUTOSAR standard for automotive systems and will cover most of your needs. Use the Arctic Core operating system to manage your real time embedded applications, use the Arctic Core communication stack to setup CAN, LIN and FlexRay communication, and use the drivers (such as PWM and ADC) to control your I/O devices. Arctic Core will let you concentrate the work on your application rather than spending time setting up the CPU.  And the best of all – Arctic Core is Open Source!
  • The hardware manufacturer: Contribute to Arctic Core by porting the MCU and hardware dependent components of AUTOSAR to your devices. This way you will make sure that your customers have a free platform of  high quality at hand for their projects. This will definitely kick-start your customers into using your products and lead to increased use of your devices in the industry. Supporting Arctic Core will be a measure of quality for your devices!
  • The embedded system enthusiast: Use Arctic Core for your embedded projects and contribute your applications, bug fixes, and added functionality back to the community.
  • For marketing purposes: As a contributor to Arctic Core you will be visible in a highly vibrant open source community. Take the chance to build yourself and you company a name by associating yourself with a high quality open source project. Make sure that the community knows about your products!

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.