Archive for July, 2009

Communication Protocols in an Embedded Platform

Sunday, 19 July, 2009

A feature-rich embedded platform needs to support many communication protocols in order to work with the many different devices that exists today. On top of the supported protocols a communication stack should be present. A stack abstracts the implementation and many protocol-specific details, and enable packaging of multiple signals into the frames of the protocols.

Protocols used by the automotive industry

The following communication protocols have been embraced by the automotive industry. For this reason these need to be supported on an embedded platform used in the automotive domain.

CAN

CAN is by far the most used protocol in the automotive domain. CAN networks form most of the communication structures in cars today. One of the reasons for the popularity of CAN is its robustness against electrical disturbances, which is an important feature when used in the harsh environment of a car. The protocol is also beginning to get a more wide-spread use outside of the automotive domain.

LIN

LIN is a light-weight and slow bus and protocol that is used to form cheap sub-networks of larger networks (for example CAN) in order to communicate with intelligent sensor devices or actuators.

FlexRay

FlexRay is the automotive industries response to the increased demand for incorporating multimedia services into the environment of the car. It is designed to be faster and more reliable than CAN, but is at the same time more expensive. The first car to support FlexRay was the BMW X5 introduced in 2006, and a more wide spread use is expected in the years to come.

Protocols used outside of the automotive industry

For embedded platforms used outside of the automotive domain a couple of more protocols are needed in order to make the support for communication of the platform complete:

Ethernet and TCP/IP

Ethernet is the worldwide standard for wired local area networks (LAN). By supporting ethernet an embedded platform ensures connectivity to an virtually unlimited set of devices. Because of the wide-spread use of ethernet, supporting this protocol definitely increases the usability of an embedded platform. To achieve even better support for LAN a TCP/IP stack should be available above the ethernet protocol.

I²C

A much used protocol for communication with peripheral devices (i.e. sensors, EEPROM, ADC and DAC) is I²C. The protocol allows a master node, for example an embedded system, to connect to I²C slave devices through a shared bus.

SPI

A more advanced peripheral communication protocol than I2C is SPI (Serial Peripheral Interface). The bus offers higher throughput at lower power requirements than I2C.

Communication supported by AUTOSAR

Most of the protocols mentioned above are supported by AUTOSAR. In particular CAN, LIN, Flexray and SPI are directly incorporated in the standard. However, in order to make an AUTOSAR system complete in the sense of support for communication, Ethernet with a TCP/IP stack and I2C would be a welcome addition. Following the AUTOSAR methodology for configuration of the system, these could be added without increasing the memory footprint of the platform. In ECU:s where these protocols are not desired, they would be configured for “zero cost operation mode” (disabled) resulting in an unaltered memory and CPU usage compared to an ordinary AUTOSAR system.

Etiketter: Automotive, AUTOSAR, CAN, Communication, Embedded Platform, Ethernet, FlexRay, I2C, LIN, SPI, TCP/IP
Postat i AUTOSAR, Automotive, Embedded Development, Embedded Platform | Inga kommentarer »

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.

Etiketter: Automotive, CAN, embedded, LIN, RTOS
Postat i Automotive, Embedded Development | Inga kommentarer »

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.

Etiketter: Automotive, embedded, Embedded Platform, RTOS
Postat i Automotive, Embedded Development | Inga kommentarer »

Open Source AUTOSAR solutions

Arctic Core

Arctic Studio

Professional AUTOSAR solutions

Arctic Core Professional

Arctic Bootloader

BSW Builder

RTE Builder

Extract Builder

SWC Builder

Popular tags

Archives

Categories