freescale powerpoint template · freescale autosar software ... industry electronics standards, see...

TM

Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2009.

Implementing AUTOSAR

Aug 27-28, 2009

Zhang EnqinShanghai Automotive Lab

TMFreescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2009. 2

Structure of this Session

►Autosar Introduction – Goals and motivation

►Freescale AUTOSAR Software

• Operating System• Microcontroller Abstraction Layer• Configuration Methodology

►Demo

• Autosar MCAL and OS Configuration with EB tresos™ Studio

TM

3Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2009.

AUTOSAR Introduction


AUTOSAR – An Industry Standard

2H 2005 1H 2006

2005 20062H 2006

Release 2.1

Improvements R2.1Specification R2.0

Phase I (2004 – 2006) Basic Software & RTE

Release 2.0

1H 2007 2H 2007 1H 2008 2H 2008 1H 2009

2007 2008 20092H 2009

Release 4.0

Improvements R4.0Specification R4.0

Specification R3.0

Concepts R4.0

Release 3.0

Phase II (2007 – 2009) Basic Software & RTE

Release 3.1


Standards driving E/E Architecture Design

► Technology partnerships and open standards encouraging “plug-and-play” approach

• FlexRay Protocol• Automotive Open System

Architecture (AUTOSAR)• Japan Automotive Software

Platform Architecture (JasPar)

► AUTOSAR Integrates Existing and EmergingIndustry Electronics Standards, see next slide for

details


AUTOSAR integration summary

Source:

Standardization

OSEK/VDX

MSRManufacturer-Supplier Relationship

Hersteller Initiative Software

ASAM ODX

HISFlexRay™ Protocol

Local Interconnect Network

Media OrientatedSystem Transport


Worldwide, OEMs and Suppliers Participate in AUTOSAR

Core Partners

Premium Members

Semi-conductors

Tier 1 StandardSoftware

Tools

AssociateMembers

CapeWare

OEM

Source: , actual status at http://www.AUTOSAR.org


AUTOSAR partnership objectives

►(AUTomotive Open System ARchitecture)

►Manage increasing E/E complexity associated with growth in functional scope

►Improve flexibility for product modification, upgrade and update►Improve scalability of solutions within and across product lines►Improve quality and reliability of E/E systems ►Enable detection of errors in early design phases.


How is this goal achieved

►Distributed System: Transparent information distribution

• Initial focus on Applications divided in software Components

• Possible distribution of parts of applications (SW-Components) at development time without the need to change the code of the SW-components

=>Break standard software and applications down into manageable parts with standardized interfaces

=> Clearly separate between hardware dependent and hardware independent parts

=>Structured & open interfaces for communication & net management


Autosar Org.

►Depending upon development phase, Autosar defines some workgroups in charge of defining specifications, requirements,…

►As an example for phase II:

WPII-1.1.1 Software Architecture and VFB

WPII-1.1.2 Vehicle and Application Mode Management

WPII-1.1.3 Debugging

WPII-1.1.4 Error Handling

WPII-1.2 General Methodology and Configuration

WPII-1.3 Functional Safety and Processes

WPII-2.1.1 COM Stack

WPII-2.1.2 FlexRay

WPII-2.1.3 MCAL

WPII-2.1.4 Diagnostics

WPII-2.2 Conformance Test Specification

WPII-3.1 Basic Software Validation

WPII-3.2 Template Validation

WPII-5.1 Problem Management

WPII-5.2 Change and Release Management

WPII-5.3 Maintenance of Specifications

WPII-10.0 Coordination of Application Interfaces

WPII-10.1 Body and Comfort

WPII-10.2 Powertrain

WPII-10.3 Chassis Control

WPII-10.4 Pedestrian and Passenger Safety Systems

WPII-10.5 Multimedia / Telematics / HMI


AUTOSAR application model

►ECU / Network view• VFB abstracts from

Network topologyHardware constraints

►Application abstraction• Hardware independant• Component based


ECU description: processor specifications, memory resources, peripherals, actuators, sensors, etc.System Constraint: networks (CAN, LIN, FlexRay), the connected ECU’s, etc


Microcontroller

Microcontroller Abstraction Layer

AUTOSAR Runtime Environment

ECU Abstraction Layer

AUTOSAR BSW Architecture—Basic Layers

Services Layer

Com

plex

Driv

er

Bas

ic S

oftw

are

Application LayerApplication

SoftwareComponent

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component


AUTOSAR BSW Architecture—Sub-Layers

Microcontroller

AUTOSAR Runtime Environment (RTE)

Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer

CommunicationServices

MemoryServices

SystemServices

Onboard DeviceAbstraction

Memory HardwareAbstraction

Communication HardwareAbstraction

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

I/O HardwareAbstraction

Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component


Autosar Layers

►AUTOSAR RTE• The Run-Time Environment (RTE) is at the heart of the AUTOSAR

stack.• The RTE provides dedicated services from the lower basic software

modules to the AUTOSAR application software-components.• These are services like memory access and intra-and inter-ECU

Communication via CAN, LIN and FlexRay.

Microcontroller


Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer


MemoryServices

SystemServices




Microcontroller DriversMemory DriversCommunication Drivers I/O Drivers


Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component


Autosar Layers

►The Service Layer provides mostly μC and ECU independent services like:

• Operating System • Memory Management• Diagnostics• Communication• Network-Management• etc.

►System Services: provided by AUTOSAR OS. Applications written for OSEK OS will run on AUTOSAR OS. AUTOSAR OS provides ScheduleTables, Tasks, Alarms, Resources, Counter, Messages, ISR, Software Free Running Timers. It also supports timing protection and memory protection.

Microcontroller


Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer


MemoryServices

SystemServices






Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component


Autosar Layers

►System Services: • The BSW-Scheduler schedules the BSW modules by triggering main

processing functions of the BSW modules. The final realization of the BSW Scheduler has to be done by the Integrator who integrates AUTOSAR BSW and applications on a dedicated ECU.

• The ECU State Manager is responsible for Initializing and de-initializing all BSW modules (including OS and RTE)The ECU State Managermanages the ECU states: OFF, RUN, SLEEP, STARTUP, SHUTDOWN.


Autosar Layers

►ECU Abstraction Layer• interfaces the drivers of the Microcontroller Abstraction Layer. It also

contains drivers for external devices.It offers an API to access peripherals and devices regardless oftheir location (μC internal/external) and their connection to the μC (port pin)

• Onboard Device Abstraction contains drivers for ECU onboard devices like system basic chip, external watchdog etc.


Autosar Layers

►Complex Device Driver• implements complex sensor evaluation and actuator control with direct

access to the μC using specific interrupts and/or complex μCperipherals (like PCP, TPU), examples:

injection controlelectric valve controlincremental position detection

Microcontroller


Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer


MemoryServices

SystemServices






Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component


Autosar Layers

►The Microcontroller Abstraction Layer provides Communication, Memory and Microcontroller specific services

Microcontroller


Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer


MemoryServices

SystemServices






Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

MCAL


Autosar Documents

►Released Autosar documents can be found on www.autosar.org►2 documents exist for each BSW module:

• SRS: Software requirement specification• SWS: Software Specification

► The SRSdescribes requirements, that must be fulfilled by a Basic Software Module (BSW). ► Chapters of SRS –documents

• Chapter 1 defines the area of application of the BSW• Chapter 2 defines the structure of the document• Chapter 3 defines the acronyms used in that document• Chapter 4 is the main chapter. • It starts with a brief description of the function that should be realized by the BSW and

continuous with the requirements.

http://www.autosar.org/


Autosar Documents

►2 documents exist for each BSW module:• SRS: Software requirement specification• SWS: Software Specification

► The SWS(Software Specification) contains the most detailed information for each Basic Software Module

► Each SWS document is structured as follows:• Chapter 1 –introduction and brief overview of functional behavior of the BSW• Chapter 2 –used acronyms• Chapter 3 –referenced documents• Chapter 4 –restrictions and applicability for the automotive domain• Chapter 5 –relation to other BSW modules and the file structure of the BSW• Chapter 6 –requirement matrix containing links to requirements from the related SRS document• Chapter 7 & 8 –contain the description of the:

functional behavior of the BSWapplications programming interface (API)

• Chapter 9 –Message sequence charts are used to describe the sequential behavior of a SWC in relation to other SWCs

• Chapter 10 –possibilities of configuration are defined• Chapter 11 –Release changes are documented


Freescale‘s offering is based on AUTOSAR Basic Software

Microcontroller


Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer


MemoryServices

SystemServices






Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

► AUTOSAR software „product“ packages from Freescale• MCAL• Operating System


Freescale Involvement in Industry Consortia

► Driving member of the OSEK/VDXTM consortium, with ownoperating system implementation

► Founding member of the LINTM consortium

► Founding member of FLEXRAYTM partnership

► First semiconductor vendor to join AUTOSARTM partnership


Freescale AUTOSAR Ecosystem: Partners

►Elektrobit Automotive (EBA)• We are reselling their AUTOSAR configuration tool (EB Tresos) and

integrate our MCAL, OS modules with this tool• EBA shares demos with higher level BSW modules

►Vector• Uses our MPC MCALs, have their own MCAL for S12X, have own OS

and AUTOSAR configuration tool

►Geensys (Embedded company providing tools, consulting and engineering services developping Autosar tool chains as well, they recently launched their first AUTOSAR Development Kit for S12x, using Freescale MCal and OS).

• Requesting MCAL and OS

►Others (no direct partners today)• Infosys• KPITCummins


.h.h

Static configuration

►Static configuration allowes to change code behaviour dependent on configuration parameters

►Functionality can be designed to be statically defined instead of definition during runtime, e.g. Creating tasks in configuration instead of during runtime with a function

► lower memory footprint, faster execution, scalable/tailored to the application needs

.h.c

Generator

.xml.oil

#Defines, Data Structures

Configuration parameters

.h.c

Static code files


Basic Software Configuration Process

.h.c

.h.c

.h.c

.h.c

MCAL Generators

Communication Services

Generator

OS Generator

RTE Generator

AUTOSAR BSWConfiguration Tool

Vehicle- or Network-level Design Tool

ECUConfigurationDescription

(XML)

ECUParameterDefinitions

(XML)


(XML)


(XML)


AUTOSAR specification status

►New in V3.0• Harmonisation/ Bugfixing, mainly for:

ECU Wake-up/ Network Start-upECU Configuration Parameter

• Modeling Guide for Application Interfaces• Requirements for CTA (Conformance Test Agency) Accreditation Bodies

►Not defined in AUTOSAR specifications today (V3.0)• Planned for AUTOSAR V4.0 end of 2009

Memory protection in RTEDual/Multi core support (RTE, OS)Configuration dependencies descriptionDebug interfaceConformance testI/O Hardware Abstraction Layer

• Not planned:OCU output compare driverStartup codeBootloader/flashloader

TM


Microcontroller Abstraction Layer (MCAL)


Microcontroller Hardware A

DC

DIO

Tim

er

I/O Drivers

PO

RT

Driv

er

AD

C D

river

DIO

Driv

er

PW

M D

river

ICU

Driv

er

PW

M

LIN

/ S

CI

CA

N

SP

I

Flas

h

WD

T

GP

T

Microcontroller Drivers Communication DriversMemory Drivers

CA

N D

river

Inte

rnal

Flas

h D

river

Wat

chdo

gD

river

LIN

Driv

er

MC

UD

river

Flex

Ray

™D

river

GP

T D

river

SP

I Driv

er

MC

U

Pow

er &

C

lock

Uni

t

AUTOSAR MCAL Package

PO

RTS

Flex

Ray


Flash EEPROM Emulation

► All MCAL drivers (1) + Flash EEPROM Emulation► Delivered with AUTOSAR conformant configuration tool.

(1) V2.1 package does not contain RAM Test module


BSW Configuration Classes

► Pre-compile configuration• Configuration parameters can not be changed after compilation• Example: Mapping of microcontroller pins to signals

► Link-time configuration• Configuration is determined by linker scripts• Configuration parameters can not be changed after link process• Purpose: provides capability to deliver object code to the integrator

► Post-build configuration• Post-build time loadable

Configuration parameters can be changed after build process without complete re-flash of ECU• Post-build time selectable

Configuration parameter set is selected from multiple configuration sets during boot timeAll possible configuration sets need to be included at compile time

• Configuration parameters are stored at a known memory location• Post-build configuration class BSW modules might also contain pre-compile or link-time

parameters (not all parameters have to be post-build)• Purpose: use one software package in different vehicles

TM


AUTOSAR Operating System


AUTOSAR Operating System

► Configurable in AUTOSAR-conformant configuration tool

► Available in Scalability Classes 1, 2, 3, 4 to fit the needs of different applications

• SC1 – deterministic RTOS baseline (tasks, events, counters, alarms, messages)

• SC2 – timing based task determinism (low-latency, precise timing for periodic tasks)

• SC3 – protected memory (MMU/MPU) for tasks avoids memory collisions for safety systems

• SC4 – timing and memory protected tasks, utilizes the full capabilities of the silicon for secure and protected RTOS designed specifically for the automobile.

System Services

Com

mun

icat

ion

Man

ager

EC

U S

tate

Man

ager

Func

tion

Inhi

bitio

nM

anag

er

Wat

chdo

gM

anag

er

Dia

gnos

tic E

vent

Man

ager

Dia

gnos

tic E

rror

Trac

er

Ope

ratin

g S

yste

m

CRC Library


AUTOSAR OS overview

►AUTOSAR OS is OSEK/VDX™ OS plus:

• New core featuresSoftware and hardware countersSchedule tables with time synchronisationStack monitoring

• Protection featuresTiming protection, memory protection and service protectionOS applications, trusted and non-trusted codeProtection hook

TMFreescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2009.

OSEK OS executes in a single ECU

OSEK OS SERVICES

ECU

PowerI/O

Memory

Task Management,Scheduler

ISR Management

Resource Management

Counters

Alarms

Events

Communication

Error Handling,Hook Routines

IT

321

!MCU


Extensions to the OSEK OS Standard

►CountersConfigurable as hardware-based or software-based

– Software► count value held in software counter► Ticked using a defined API : IncrementCounter()

– Hardware► Count value held in hardware register► No standardised interface in OS for manipulating hardware counters► GPT can be configured to trigger an OS counter (V2.1)

Added new APIs for SWFT support (V2.1)– GetCounterValue ()– GetElapsedCounterValue ()

►AlarmsSetRelAlarm() with increment parameter equal to 0 now defined to mean a full wrap of the underlying counterHave a 4th action of INCREMENTCOUNTER to allow counter cascading for software counters


Extensions to the OSEK OS Standard

►Interrupt manipulation APIDisable(Enable)AllInterrupts() and Suspend(Resume)AllInterrupts() can be called before StartOS() is calledAdded new APIs for Interrupt Source manipulation:

– DisableInterruptSource(<ISR ID>)– EnableInterruptSource(<ISR ID>)

►Hook FunctionsThe OS Hook Routines STARTUPHOOK; SHUTDOWNHOOK and ERRORHOOK can be defined per OS-Application.If Hook Routines STARTUPHOOK_<AppID>; SHUTDOWNHOOK _<AppID> or ERRORHOOK _<AppID> are defined, theses versions are called after the OS level Hook routines.The OS-Application level Hook routines are executed with the access rights of the OS-Application.


Extensions to the OSEK OS – Schedule Tables

• A static definition of alarm expiries called expiry pointsEach expiry point holds 1 or more statically defined actions

– ACTIVATETASK or SETEVENT allowed• Define period of repetition

E.g. Schedule has a period of 25 milliseconds• Alarms defined at offsets within schedule

Activate TaskB at 3ms, 17ms and 199ms• Tied to either a unique hardware counter or a software counter

But counter can be driven any source– Local time, network (global) time, ABS pulses, crank rotations, error conditions, button

presses etc.Options to synchronise the schedule with global time when underlying counter is driven by local time



• Starting absolute

• Starting relative



• Synchronizing with a global Time

• Asynchronous start with hard synchronization



• Synchronizing with a global Time

Asynchronous start with smooth synchronization

Synchronous startNew API in V2.1 StartScheduleTableSynchron ()


Extensions to the OSEK OS – Protection

► The AUTOSAR concept requires that software components are isolated from each other at runtime

Eases integration debugging issuesAllows arguments about prevention of fault propagation to be made in the system safety casePrevents loss of significant proportion of vehicle functionality due to single “rogue” software component

► AUTOSAR OS provide protection facilities to isolate software components and protect the integrity of the OS itself

– Memory Protection– Timing Protection– Service Protection


Extensions to the OSEK OS - Trusted and Non-Trusted code

► Integrity level: Concept of Trusted and Non-Trusted code

► The OS itself is „trusted“ code

► OS-Application: A block of software including Tasks, interrupts, hooks and trusted functions that form a cohesive functional unit. Only trusted applications can provide trusted functions and Category1 ISRs.Trusted: An OS-Application that is executed in privileged mode and has unrestricted access to the API and hardware resources.Non-trusted: An OS-Application (its Tasks and ISRs) that is executed in non-privileged mode has restricted access to the API and hardware resources.

► Trusted FunctionA service provided by a trusted OS-Application that can be used by other OS-Applications (trusted or non-trusted).


► Scheme is largely aimed at protecting► multiple peer SW-Cs resident on the same ► microcontroller

► Protection managed at level of smallest OS ► object

Tasks/ISRs (minimum OS-Application)

► Each task/ISR has Its own stack spaceIts own private data

► Tasks/ISRs are also grouped into “OS-Applications”Essentially to define a memory protection regionTasks/ISRs in the same OS-Application can read/write to shared memory

► Implementations can optionally prevent read access to OS-Application data

► Implementations can optionally prevent execution of OS-Application code

Extensions to the OSEK OS - memory protection


►The Protection Hook• ProtectionReturnType ProtectionHook ( StatusType Fatalerror )

• is called on protection errors (Fatalerror),• is impemeted by the application and defines the action by the return value:

Kill the faulty Task/Category 2 ISR ORKill the faulty OS-Application ORKill the faulty OS-Application and restart the OS-Application. ORCall ShutdownOS().

• If the faulty Task/ISR cannot be found,the OS-Application is killed, if the faulty OS-Application cannot be found, ShutdownOS() is called.• If no Protection hook is defined,

ShutdownOS() is called.

Protection Hook


Usage of Memory Protection

►A Non-trusted OS application task• Can only access the memory it needs• Therefore not this OS application task is protected, but all other tasks

are protected from it

►Memory protection can be used, e.g.,• To separarate different applications on one MCU• For isolating controller functionality from independent sub-suppliers• To fulfill safety constraints • As a debug feature (faulty memory access is prevented, stack overflow

is prevented, protection hook is called)

►Memory protection MUST be supported by on-chip MPU


Extensions to the OSEK OS - Service protection

►Prevent one OS-Application manipulating the objects of another OS-Application

All OS objects are assigned to at most one OS-ApplicationAccess permissions are defined between objects in OS-Applications

►Check for invalid (not allowed in context) calls to be made on OS objects

E.g. activating a task that you are not configured to activate

►Additional checks (in addition to the OSEK OS extended status) for API calls

Undefined OSEK OS behaviour is defined– E.g. leaving the scope of a task entry function without calling TerminateTask()

►Only in conjunction with memory protection And requires OS to run in OSEK “Extended” status for full protectionThere is no service protection with “Standard” status because it would have to check all “Extended” status issues anyway

►Protection Hook is called upon detection of a service protection error


Extensions to the OSEK OS – Hardware protection; Trusted Functions

►Hardware protection (if supported by hardware)The OS shall execute non-trusted OS-Applications in non-privileged modeAccess control registers cannot be accessed by non-trusted OS-Applications and trusted OS-Applications can only access the necessary.If an instruction exception occurs (e.g. division by zero), the Protection hook is also called

►Trusted FunctionsMust be defined in trusted OS-ApplicationsCan be called from non-trusted OS-Applications

– Only by granting access and using special API: StatusType CallTrustedFunction (FunctionIndex, FunctionParams)

The OS does not support »non-trusted services«


Usage of Timing Protection & Global Time

►Timing Protection• Execution time enforcement

Bounds the execution of ISRs, resource locks and interrupt disabled sections at runtime to a statically configured value („time budget“)

• Arrival rate enforcementBounds the number of times that an ISR can execute in a given timeframe to a statically configured limit

• Protection Hook is called upon detection of a timing protection error

►Global Time / Synchronization Support• Requires a global time source, e.g. the FlexRay network time• This feature allows schedule tables to be synchronized with a global

time through special OS service calls


Extensions to the OSEK OS – General Implications

► AUTOSAR means that application software components don’t see the OS directly

They only see and communicate through the RTEOnly basic software will use the OS interface directly

► If memory protection is used, all SW-C’s must be subject to protection mechanisms

If not, they would have direct access to memory-mapped I/O and violate the AUTOSAR goal of SW-Cs only communicating with hardware via an AUTOSAR interface

– Rather like Windows 3.11 ☺

► All SW-C runnables mapped to a task must belong to the same protection boundary

There is no protection between runnables in the same task

► Timing protection means no unmanaged ISRs (Category 1 ISRs in OSEK terminology)

Not managed by OS so difficult to account for in protection schemes– Adding management would make them almost Category 2 anyway


OSEK OS (all conformance classes)

Counter Interface

Schedule Tables

Stack Monitoring

Protection Hook

Timing Protection

Global Time/Synchronization Support

Memory Protection

OS Applications

Service Protection

CallTrustedFunction

Sca

labi

lity

Cla

ss 1

Sca

labi

lity

Cla

ss 2

Sca

labi

lity

Cla

ss 3

Sca

labi

lity

Cla

ss 4

AUTOSAR OS Scalability Classes 1–4

TM


AUTOSAR Configuration


►EB tresos Studio is a easy-to-use tool for ECU standard software configuration, validation and code generation

EB tresos Studio

► Full support for the AUTOSAR standard► Full support for the Freescale AUTOSAR

software and the EB tresos AutoCore► Will be used by Freescale for both OS and

Mcal configuration, starting in August 2008

► Integrated, graphical user interface ► Based upon Eclipse and open standards► Online-help and parameter-specific help

Source: Elektrobit


Main Window

Node Outline

Error & ProblemMessages

ParameterInformation

EditorProject Browser

Source: Elektrobit


Errors & Warnings

Link toerror or warning

User corrects the problem

Interactive problem resolution

Source: Elektrobit


Parameter Definition

Parameter "OsCounterType"

… and its corresponding entry in the description file (*.EPD)

Jump to link

Source: Elektrobit


Parameter Description Files – EPD/EPC

Source: Elektrobit

EPD

EB tresos StudioConfigurator write

read

BSWModule

Description

EB tresos StudioGenerator

c, hwrite

read

c, htemplates

read

BSW Module Configuration

GeneratedCode

Code Templates

AUTOSAR Files

Elektrobit Files

Generated Files

Legend

read

EPC


Parameter Description Files – XDM

Source: Elektrobit

XDM


read

BSWModule

Description


c, hwrite

read

c, htemplates

read


GeneratedCode

Code Templates

AUTOSAR Files

Elektrobit Files

Generated Files

Legend

read

EPD

convert

XDM

EPCimport/export


XDM


arxml

SW-CDescription

arxml

import

read

BSWModule

Description

dbc,ldf,

fibex1)

LegacyDescription


c, hread

htmldocxml

Generated Documentation

(optional)

write

write

read

c, htemplates

read


GeneratedCode

Code Templates

read(RTE Generator only)

AUTOSAR Files

Elektrobit Files

Generated Files

Legend

read

System Description

read

EPD

convert

XDM

EPCimport/export

1) currently in development

Parameter Description Files – Beyond MCAL

Source: Elektrobit


Configuration Checking

Hard-to-find errors detected instantly

Error:ID does not start with zero

Source: Elektrobit


Generate Project

Generate code via command line

click

Generate code from GUI

Source: Elektrobit


► User-Friendly GUIhelps to avoid errorseasy navigationone integrated tool environment

► Open Interfacesintegration of user-specific BSW modulesintegration of user-specific importers and exporterscustomizable through Java plug-ins

► Integrated Environmentcomplete AUTOSAR standard core configurationplanned to be extended with more EB tools by Elektrobit(SW-C Editor, Inspector, etc.)

EB tresos Studio - Summary

Source: Elektrobit


Folder Structure of MCAL Package

.plugins eclipse plugins Adc_TS_T2D4M1I3R0

autosar

config

generate_LT

generate_PB

generate_PC

Can.epd

Can.epc

Can.xdm

include

src Can_PBCfg.c

include

src

include

src

Can_Cfg.h

plugin.xml

Can_TS_T2D4M1I3R0

Dio_TS_T2D4M1I3R0

Fee_TS_T2D4M1I3R0

Wdg_TS_T2D4M1I3R0

WdgIf_TS_T2D4M1I3R0

common_freescale_mpc5516

can_freescale_mpc5516

adc_freescale_mpc5516

canif_freescale_mpc5516

dio_freescale_mpc5516

fee_freescale_mpc5516

fls_freescale_mpc5516

fr_freescale_mpc5516

gpt_freescale_mpc5516

cfg1

ssc

inc

src

doc

inc

lib

mak

srcCan.c

Can_Irq.c

Makefile

Can.h

can_Irq.h

AUTOSAR_MPC5516_CAN_UM.pdf

Can_Cfg.h

Can_PBcfg.c

AUTOSAR_MPC5516_CAN_IM.pdf

► Complete source code► Makefile► User Manual► Integration Manual

► Complete source code► Makefile► User Manual► Integration Manual

► Parameter description files(.epd/.epc + .xdm)

► Generators for Pre-Compile, Post-Build, Link-Time

► EB tresos Studio Plugin

► Parameter description files(.epd/.epc + .xdm)

► Generators for Pre-Compile, Post-Build, Link-Time

► EB tresos Studio Plugin


Live Demo