Hands-On Workshop: AUTOSAR Training (Reserved Seat Required) - NXP
Hands-On Workshop: AUTOSARTraining (Reserved Seat Required)FTF-ACC-F1243Marius Rotaru Technical Leader - Automotive SoftwareJUNE.2015TMExternal Use
Agenda AUTOSAR Motivation and Principles Visionand Objectives Development Architecture MigrationCooperationof the Standardof the Standard AUTOSAR Configuration Methodology & Tools AUTOSAR MCAL AUTOSAR OS Examples: Hands-on Training LAB1:Blinking LED LAB2:Dimming LEDTMExternal Use1#FTF2015
AUTOSAR Motivation andPrinciplesTMExternal Use2#FTF2015
Embedded SoftwareAndroid11.8 MLoCMars Curiosity Rover5MLoCF-35 Joint Strike Fighter23.5 MLoCThere is A LOT of EmbeddedSoftware in Automotive!Mercedes S Class s-of-code/TMExternal Use3#FTF2015
AUTOSAR StandardizationTechnology partnerships and open standards encouraging “plug-and-play” approachFreescale, a reliable partner for automotivesoftware and hardware innovation:StandardizationMSRManufacturer-Supplier Relationship Driving member of the OSEK/VDXTMconsortium, with own operating systemimplementationOSEK/VDXHersteller Initiative SoftwareASAM ODX Founding member of the LINTM consortiumFlexRay ProtocolHIS Founding member ofFLEXRAYTMpartnershipLocal Interconnect NetworkMedia OrientatedSystem Transport First semiconductor vendor to joinAUTOSARTM partnershipSource:(AUTomotive Open System ARchitecture)TMExternal Use4#FTF2015
AUTOSAR VisionAUTOSAR aims to improve the complexity management of integrated E/E architecturesthrough increased reuse and exchangeability of software modules between OEMs andsuppliers.OEM bOEM aExchangeabilitybetweenOEM csuppliers’solutionsPlatform b.1Platform b.2Platform b.nSupplier A Chassis Safety Body/ComfortPlatform a.1Platform a.2Platform onsSupplier B Chassis Safety TelematicsSupplier C Body/Comfort Powertrain TelematicsOEM fPlatform c.1Platform c.2Platform c.nOEM dPlatform d.1Platform d.2Platform d.nOEM eSource:Autosar GuidedTour.pdfExchangeabilitybetween vehicleplatformsPlatform f.1Platform f.2Platform f.nPlatform e.1Platform e.2Platform e.nTMExternal Use5#FTF2015
AUTOSAR VisionAUTOSAR aims to standardize the software architecture of ECUs. AUTOSAR paves the way forinnovative electronic systems that further improve performance, safety and environmental friendliness.Customer needsYesterdayAUTOSAR Adaptive Cruise Control Lane DepartureWarning Advanced FrontLighting SystemApplication SoftwareSoftwarestandardizedUsing standardsHW-specificHardwareHardware Communication StackOSEKDiagnosticsCAN, FlexRayHardware and software will be widely independent of each otherDevelopment can be de-coupled by horizontal layers. This reduces development timeand costsThe reuse of software increases at OEM as well as at suppliers. This enhances qualityand efficiencySource:Autosar GuidedTour.pdfTMExternal Use6#FTF2015
AUTOSAR ObjectivesPO1:Transferability ofsoftwarePO6:Sustainable utilization ofnatural resourcesPO2:Scalability to differentvehicle and platformvariantsPO3:Different functionaldomainsPO4:Definition of an ethodologyPO7:Collaboration betweenvarious partnersPO8:Standardization of basicsoftware functionality ofautomotive ECUsPO9:Applicable automotiveinternational standardsand state-of-the-arttechnologiesPO5:Dependable systemsSource: AutoSAR RS ProjectObjectives.pdfAutosar GuidedTour.pdfTMExternal Use7#FTF2015
AUTOSAR Main Working TopicsArchitecture Architecture:Software architecture including a complete basic softwarestack for ECUs — the so called AUTOSAR Basic Software —as an integration platform for hardware independent softwareapplications. Methodology:Defines exchange formats and description templates toenable a seamless configuration process of the basicsoftware stack and the integration of application software inECUs. It includes even the methodology how to use thisframework. Application Interfaces:Specification of interfaces of typical automotive applicationsfrom all domains in terms of syntax and semantics, whichshould serve as a standard for application licationMethodologyInterfacesSource:Autosar GuidedTour.pdfTMExternal Use8#FTF2015
AUTOSAR — Concept and Functional DomainFunctional DomainsThe AUTOSAR project objectiveswill be met by specifying andstandardizing the centralarchitectural elements acrossfunctional domains, allowingindustry competition to focus faceTelematicsBody andComfortCooperate on standards,compete on implementation.Source:Autosar GuidedTour.pdfTMExternal Use9#FTF2015Passenger‘centric’
AUTOSAR — Cooperation Structure and PartnersAutoSAR Partners (Nov. 2014)TMExternal Use10#FTF2015Source: , actual status at http://www.AUTOSAR.org
Basic AUTOSAR ApproachAUTOSARSW-CnIndependent of l Integration1.1Virtual Functional Bus.2Virtual Functional Bus2Introduction of HardwareAttributesTools supporting developmentof software componentsECUDescriptions5ECU ISeparation of system into itsECU (plus commoninfrastructure).ECUDescriptionECU IIAUTOSARSW-C 1Run-Time EnvironmentAUTOSARSW-C 2RTEAUTOSARSW-C36BasicSoftwareRTE.6AUTOSARSW-C nRTEBasicSoftwareFlex RaySource:TM11ECU Description4System Constraints5Mapping of SW-C onspecific ECU6Configuration of BasicSoftware Modules(BSW) and Run-TimeEnvironment (RTE)ECU nBasicSoftwareGatewayExternal Use3System ConstraintDescription5ECUDescriptionECU ConfigurationIntegration of SW-C viaVirtual Functional Bus(VFB)43Holistic view of the entiresystem, both software andhardware.Software Component(SW-C) description#FTF2015CAN6SystemDescription
AUTOSAR Architecture — Components and Interface ViewSource:TMExternal Use12#FTF2015
AUTOSAR Layered Software ArchitectureSoftwareComponentsBasic structure distinguishes four basic layers.Application LayerBasic SoftwareRuntime EnvironmentECUResourcesBasic SoftwareMicrocontrollerSource:TMExternal Use13#FTF2015
AUTOSAR Layered ArchitectureThe AUTOSAR Basic Software is further divided in the layers: Services, ECUAbstraction, Microcontroller Abstraction and Complex Drivers.Application LayerRuntime EnvironmentServices LayerComplexDriversECU Abstraction LayerMicrocontroller Abstraction LayerMicrocontrollerSource:TMExternal Use14#FTF2015
AUTOSAR Layered ArchitectureThe Basic Software Layers are further divided into functional groups. Examples ofServices are System, Memory and Communication Services.Application LayerRuntime EnvironmentSystem ServicesMemory ServicesCommunication ServicesOnboard DeviceAbstractionMemory HardwareAbstractionCommunicationHardware AbstractionMicrocontroller DriversMemory DriversCommunication DriversI/O Hardware AbstractionI/O DriversSource:MicrocontrollerSource:TMExternal Use15#FTF2015ComplexDrivers
AUTOSAR Freescale Solution Freescale Software Products includethe AUTOSAR Operating System,AUTOSAR MCAL Drivers and ComplexDevice Drivers The full AUTOSAR RTE (RuntimeEnvironment) stack is available throughour integration partnersIntegrationPartnersAUTOSAR stackFreescaleOS MCAL CDDTMExternal Use16#FTF2015
AUTOSAR Documentshttp://wwww.autosar.orgPublished ReleasesFor information only, see disclaimerTwo documents exist for each BSW module:- SRS: Software Requirement Specification- SWS: Software SpecificationTMExternal Use17#FTF2015
AUTOSAR — Application MigrationUncontrolled software designStructured design12Partial introduction of AUTOSAR BSWwith legacy SW-Cs to BSW adaptersSingle-sided RTE with softwarecomponents (SW-C) and legacy BSW34Complete AUTOSAR BSW withadapters for legacy SW-CsFully AUTOSAR compliant ECU5Hardware6Legacy softwarecomponentsAUTOSAR compliantSW componentsRTETMExternal Use18#FTF2015SoftwareAdapterAUTOSAR BSWSource:Autosar GuidedTour.pdf
AUTOSAR ConfigurationMethodology and ToolsTMExternal Use19#FTF2015
Basic Software Configuration ProcessFreescale AUTOSAR Integration Partners receive Freescale MCALand OS releases for pre-integration into their proprietary AUTOSARBSW products.TMExternal Use20#FTF2015
AUTOSAR Methodology and Templates — Waterfall View.arxmlSystemConfigureConfiguration SystemInput: SystemBSW Specific (MCAL/OS).arxmlSystemExtract ECUConfiguration SpecificDescription: InformationSystem.arxmlECU Extract onfigurationValuesSystem .exeGenerateExecutableECUExecutableECUThe AUTOSAR Methodology is foreseen to support activities, descriptions and use of tools in AUTOSAR The notation of the Software Process Engineering meta-model (SPEM) is used The AUTOSAR methodology is not a complete process description but rather a common technical approach for some steps of systemdevelopment Outside the scope of the AUTOSAR standard is: Description of tools (which add value to the ‘Activities’ in the methodology) Definition of roles and responsibilitiesTMExternal Use21#FTF2015
Software Module Static/Generated PartsOne AUTOSAR BSW module normally consists of three main pieces: Software module source code: itis a static part of software module, which is not ECU configurationdependent Software module VSMD (Vendor Specific Module Definition): anXML file that describes software module configuration capabilities(EPD) Software module generator: processECU configuration (also an XML file but different to VSMD)(EPC) and generates software module(s)TMExternal Use22#FTF2015
Basic Software Configuration ProcessAUTOSAR SystemDesign ToolRTEGenerator.h.cOSGeneratorAUTOSAR BSWConfiguration ML)(XML)MCALGenerators.h.cTMExternal Use23#FTF2015
ElektroBit (EB) Tresos Studio EB tresos Studio is an easy-to-use tool for ECUstandard software configuration, validation andcode generation Full support for the AUTOSAR standard Full support for the Freescale AUTOSARsoftware and the EB tresos AutoCore Integrated, graphical user interface Based upon Eclipse and open standards Online-help and parameter-specific helpTMExternal Use24#FTF2015
AUTOSAR BSW Configuration ToolExample: Tresos ECU Graphical representationof ECU configurationdescription (ECD) Import/export of ECD Easy configuration ofAUTOSAR BSW usingpre-compilemethodologySource: Elektrobit AutomotiveTMExternal Use25#FTF2015
Main rmationError & ProblemMessagesSource: ElektrobitTMExternal Use26#FTF2015
Errors & WarningsUser correctsthe problemLink toerror or warning Interactive problemresolutionSource: ElektrobitTMExternal Use27#FTF2015
Parameter DefinitionJump to linkParameter"OsCounterType" and its correspondingentry in the descriptionfile (*.EPD)Source: ElektrobitTMExternal Use28#FTF2015
Parameter Description Files — EPD/EPCLegendEPDAUTOSAR FilesBSWModuleDescriptionElektrobit FilesBSW ModuleConfigurationreadGenerated FilesEB tresos StudioConfiguratorwriteEPCreadreadEB tresos StudioGeneratorreadc, htemplatesSource: ElektrobitTMExternal Use29#FTF2015CodeTemplateswritec, hGeneratedCode
Parameter Description Files — SAR FilesElektrobit FilesEPCimport/exportBSW ModuleConfigurationGenerated FilesEB tresos StudioConfiguratorwriteXDMread XDM is a proprietary format (EB) providingenhanced usability features during configurationwith EB tresos Studio EPD is the standard AUTOSAR format. Thisallows the Freescale AUTOSAR software to beused with any other AUTOSARConfiguration/Generation toolsTMExternal Use30#FTF2015readwriteEB tresos StudioGeneratorc, hGeneratedCodereadSource: Elektrobitc, htemplatesCodeTemplates
AUTOSAR Configuration Classes Configuration classes (for parameters): The development of BSW modules involve the following developmentcycles: compiling, linking and downloading of the executable to ECUmemory Configuration of parameters can be done in any of these process-steps:pre-compile time, link time and post-build timeTMExternal Use32#FTF2015
AUTOSAR Configuration ClassesThe AUTOSAR Basic Software supports the following configuration classes (forparameters):1.Pre-compile time Preprocessor instructions Code generation (selection or synthetization)2.Link time Constant data outside the module; the data can be configured after the module hasbeen compiled3.Post-build time Loadable constant data outside the module. Very similar to [2], but the data is locatedin a specific memory segment that allows reloading (e.g. reflashing in ECU productionline)Independent of the configuration class, single or multiple configuration sets can be provided by means ofvariation points. In case that multiple configuration sets are provided, the actual used configuration set is tobe chosen at runtime in case the variation points are bound at runtime.TMExternal Use33#FTF2015
AUTOSAR MCALTMExternal Use34#FTF2015
AUTOSAR — Microcontroller Abstaction LayerApplication LayerThe Microcontroller Abstraction Layer is the lowest software layer of the BasicSoftware.It contains internal drivers, which are software modules with direct access to the µCand internal peripherals.System kMake higher software layers independent of µCMemoryServicesCommuni-cationServicesMemoryHW Abstr.COM HWAbstr.MemoryDriversCommuni-cationDriversMemory DriversCommunication DriversPORT DriverDIO DriverADC DriverDIOADCPWMCCU#FTF2015PWM DriverICU DriverOCUCANLIN orSCISPIEEPROMFLASHMCUPower &Clock UnitWDTGPTSource:35Group ofSoftwaremodules ofsimilar typeI/O DriversOCU DriverEthernet DriverFlexRay DriverCAN DriverLIN DriverSPI Handler Driverinternal EEPROM Driverinternal Flash DriverRAM TestFlash TestCore TestMCU DriverWatchdog DriverGPT DriverMicrocontrollerTMExternal UseI/ODriversMicrocontroller (µC)PropertiesImplementation: µC dependentUpper Interface: standardized and µC independentMicrocontroller DriversI/O eComplex DriversRTE
AUTOSAR — Microcontroller Abstaction LayerApplication LayerMicrocontroller DriversSystem ServicesOnboardDev.Abstr.MicrocontrollerDrivers Driversfor internal peripherals (e.g. Watchdog,General Purpose Timer) Functions with direct µC accessMemoryServicesCommuni-cationServicesMemoryHW Abstr.COM troller (µC)Microcontroller DriversCore TestMCU DriverWatchdog DriverGPT DriverSource:TMExternal Use36#FTF2015DIOADCPWMCCUOCUCANLIN orSCISPIEEPROMFLASHMCUPower &Clock UnitWDTGPTMicrocontrollerI/O HWAbstractionI/ODriversComplex Drivers RTE
AUTOSAR — Microcontroller Abstaction LayerApplication LayerMemory Drivers RTEThe Memory Hardware Abstraction is a group of modules which abstracts from thelocation of peripheral memory devices (on-chip or on-board) and the ECU hardwarelayoutExample: on-chip EEPROM and external EEPROM devices are accessible via the samemechanismThe Memory Drivers are accessed via memory specific abstraction/emulation modules(e.g. EEPROM Abstraction)System oryServicesCommuni-cationServicesMemoryHW Abstr.COM troller (µC)Memory HardwareAbstractionFLASH EEPROMEmulationMemory DriversDIOADC#FTF2015PWM37CCUExternal UseOCUTMCANEEPROMLIN orSCIinternal EEPROM DriverFLASHSPIinternal Flash DriverRAM TestFlash TestMCUPower &Clock UnitWDTGPTMicrocontrollerI/O HWAbstractionI/ODriversComplex Drivers
AUTOSAR — Microcontroller Abstaction LayerApplication LayerCommunication DriversSystem ServicesOnboardDev.Abstr.MicrocontrollerDrivers Driversfor ECU onboard (e.g. SPI) and vehiclecommunication (e.g. CAN) OSI-Layer: Part of Data Link LayerMemoryServicesCommuni-cationServicesMemoryHW Abstr.COM troller (µC)Communication DriversEthernet DriverFlexRay DriverCAN DriverLIN DriverSPI Handler Driver38#FTF2015DIOExternal UseADCSource:TMPWMCCUOCUCANLIN orSCISPIEEPROMFLASHMCUPower &Clock UnitWDTGPTMicrocontrollerI/O HWAbstractionI/ODriversComplex Drivers RTE
AUTOSAR — Microcontroller Abstaction LayerApplication LayerI/O DriversSystem ServicesOnboardDev.Abstr.MicrocontrollerDrivers Driversfor analog and digital I/O (e.g. ADC,PWM, DIO)MemoryServicesCommuni-cationServicesMemoryHW Abstr.COM troller (µC)I/O DriversADC DriverPWMADC39#FTF2015DIOPWM DriverCCUExternal UsePORT DriverICU DriverOCUSource:TMDIO DriverOCU DriverCANLIN orSCISPIEEPROMFLASHMCUPower &Clock UnitWDTGPTMicrocontrollerI/O HWAbstractionI/ODriversComplex Drivers RTE
AUTOSAR — Complex Device DriversApplication LayerSystem ServicesOnboardDev.Abstr.MicrocontrollerDriversAn example is to implement complex sensor evaluationand actuator control with direct access to the µC usingspecific interrupts and/or complex µC peripherals e.g.COM rsExample:Complex DriversInjection ControlµCe.g. PCPe.g. CCU#FTF2015Electric Valve ControlTMIncremental Position DetectionSource:e.g. TPUProperties: Implementation: highly µC, ECU and application dependent Upper Interface to SW-Cs: specified and implemented according toAUTOSAR (AUTOSAR interface) Lower interface: restricted access to Standardized Interfaces40MemoryHW Abstr.I/O HWAbstractionMicrocontroller (µC)Fault Monitoring DriversCore and Peripheral Self TestsMicroController Library (MCL)CRC DriverExternal UseCommuni-cationServicesComplex Driver XY MemoryServicesComplex DriversRTEA Complex Driver is a module which implements nonstandardized functionality within the basic software stack.
Freescale AUTOSAR MCAL ProductModule Parameter Definition in AUTOSAR formatModule Parameter Definition in Tresos formatPost-build source files macros and templatesPre-compile source files macros and templatesModule BSWMD fileModule driver header filesModule driver source filespackage name schemadefined by ElektrobitModule TS TxDyMzIaRbX Target (2 — Freescale PPC)Y Derivate ( 34 — MPC5748G )Z Module Major & Minor VersionA Module Revision VersionB ReservedTMExternal Use41#FTF2015
AUTOSAR OSTMExternal Use42#FTF2015
History: OSEK/VDX May 1993 1994 2nd release of specification packageFeb 2005 French cars manufacturers Renault and PSA Peugeot Citroën, which had a similarproject called VDX (Vehicle Distributed eXecutive), joined the consortiumOct 1997 Funded by a German company consortium BMW, Robert Bosch GmbH,DaimlerChrysler, Opel, Siemens, and Volkswagen Group in order to create an openstandard for the automotive industryOpen Systems and their Interfaces for the Electronics in Motor VehiclesSpecification 2.2.3 of OSEK OSGoals: portability and reusabilityTMExternal Use43#FTF2015
AUTOSAR OSApplication Layer AUTOSAR OS is OSEK/VDX OS plus:System onServicesCOMHWAbstr.Communi-cationDriversI/O HWAbstractionI/ODriversComplex DriversRTEMicrocontroller (µC) New core features Softwareand hardware counters Schedule tables with timesynchronisation Stack monitoringBasic SoftwareMode Manager(BswM)CommunicationManager (ComM)Watchdog Manager(WdgM)Time Service(Tm)SynchronizedTime-baseManager (StbM)#FTF2015Crypto ServiceManager (Csm)44Diagnostic Log andTrace (Dlt)External UseDefault ErrorTracer (Det)TMFunction InhibitionManager (FiM)protection, memory protectionand service protection OS applications, trusted and nontrusted code Protection hookECU StateManager (EcuM) TimingDiagnostic EventManager (Dem)Protection featuresAUTOSAR OS System Services
AutoSAR OS — Application and Trustedand Non-Trusted Code Integrity level: trusted and non-trusted code OS application Ablock of software including tasks, ISRs, hooksand trusted functions Trusted: An OS application that has unrestrictedaccess Non-trusted: An OS application that hasrestricted access Trusted function Aservice function with unrestricted access Provided by a trusted OS applicationTMExternal Use45#FTF2015
AUTOSAR OS — Usage of Memory Protection A Non-trusted OS application task Canonly access the configured resources (i.e. Memory, peripherals, .) Therefore this task is unabled to interfere with other components in thesystem Memory protection can be used, e.g., Tosepararate 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 isprevented, protection hook is called) Memory protection MUST be supported by on-chip hardware resources(i.e. MPU)TMExternal Use46#FTF2015
AUTOSAR OS — Usage of Service Protection Service Protection Protectionagainst faulty/corrupted OS service calls by an OS Application Examples OSApplication calls ShutDownOS() OS Application tries to execute ActivateTask() on a task belonging to anotherOS Application ProtectionHook is called upon detection of a service protection errorTMExternal Use47#FTF2015
AUTOSAR OS — Usage of Timing Protection& Global Time Timing Protection Executiontime enforcement Boundsthe execution of ISRs, resource locks and interrupt disabled sections atruntime to a statically configured value (“time budget“) Arrivalrate enforcement Boundsthe number of times that an ISR can execute in a given timeframe to astatically configured limit Protection Hook is called upon detection of a timing protection violationGlobal Time / Synchronization Support Requiresa global time source, e.g. the FlexRay network time This feature allows schedule tables to be synchronized with a global timethrough special OS service callsTMExternal Use48#FTF2015
OSEK OS (all conformance classes)Counter InterfaceSchedule TablesStack MonitoringProtection HookTiming ProtectionGlobal Time/Synchronization Support OS ApplicationsService ty Class 4Scalability Class 3 Memory ProtectionExternal Use Scalability Class 2Scalability Class 1AUTOSAR OS Scalability Classes 1–4
Freescale AUTOSAR OS Application ArchitectureEB Tresos“C” codeApplicationconfiguration file (EPC)User’ssourcecodeSystemGenerator“C” code“C” codeSysgen filesCompilerOSsourcecodeLibraryMake toolThird party tools & related filesLinkerOS components, tools & related filesExecutable fileUser written / definedTMExternal Use50#FTF2015Library
AUTOSAR Hands-On TrainingTMExternal Use51#FTF2015
What‘s on Your DeskGreenHillsProbeMPC5748GBoardMPC5748GSoCLEDs & TrimmerTMExternal Use52#FTF2015
MPC5748G — Block DiagramTMExternal Use53#FTF2015
LAB1 Blinking LED Objective Get started with AutoSAR and Blinking LEDEnvironment AutoSARMCAL and AutoSAR OS v4.0 Tool: Elektrobit tresos Studio 2014.2.1 Compiler: GreenHills for PPC Debugger: GreenHills Probes Hardware: MPC5748G Evaluation Board Functional description TheAutoSAR BSW modules Mcu, Dio, Port, Os, EcuM, Rte are appliedto build an application which toggles an LED every second.TMExternal Use54#FTF2015
PORT/DIO Modules — Functional Overview Port Initialization of all pins and ports ofthe MCU Reinitialization with alternateconfigurations at runtime possible Reconfiguration of pins at runtime Port Pin Function Assignment (GPIO,Adc, SPI, PWM, .) PadSelection implicitly via hardwareassignment PortPin is the only structural elementTMExternal Use55#FTF2015Dio Provides APIs to read and write GPIOports/pins Requires an initialized Port module Pins/ports need to be initialized via Portmodule API synchronous and unbuffered Structural Elements: Channel (single pin) ChannelGroup (adjacent pins in the sameport) Port (aggregates Channels andChannelGroups)
PORT/DIO Modules — Freescale ImplementationPort Access:Port Init(.)Port SetPinDirection(.)Port RefreshPinDirection(.)Port SetPinMode(.)Dio Write Accesses:Dio WriteChannelDio WritePortDio WriteChannelGroupDio Read Accesses:Dio ReadChannelDio ReadPortDio ReadChannelGroupTMExternal Use56#FTF2015
LAB1: Blinking LED1.2.3.4.5.6.7.Opening a Tresos ProjectAdding an AUTOSAR Module to the ProjectParameters Configuration for DIO and PORTCode GenerationGreenHills IntegrationCompilation and DebuggingAUTOSAR Runtime Application FlowTMExternal Use57#FTF2015
Opening a Tresos Project1. File - Import - General - Existing Projects into Workspace - Select rootDirectory - Browse to c:\eb\tresos\workspace - Select Lab1 - FinishTMExternal Use58#FTF2015
Opening a Tresos Project2. Right click on Training - select Load configurationTMExternal Use59#FTF2015
Adding an AutoSAR Module to Project1. Right Click on Training and select Module Configurations 2. From List of Available Modules select Dio and import it into ModuleConfigurations List - Press OkTMExternal Use60#FTF2015
Parameters Configuration Objective Youstart with an empty/initial ECU-configuration. This step describes how tocomplete this configuration for your first project. Therefore, parameters willbe modified and containers will be added Procedure Thenext slides will show which Containers/Parameters to add/change To open a module configuration, double click the module in the ProjectExplorer window To navigate within a previously opened module configuration, use theOutline window on the bottom left side To change parameter, click on that parameter in Outline window To add a container, click on the collection item of this container type (e.g.DioPort). You see a listview in the main window which lets you add newentries by clicking the button To edit a previously added container in the main window, click on it in theOutline windowTMExternal Use61#FTF2015
Parameters Configuration Port Open and Explorer the container“Port” Open PortConfigSet 0 container Add a PortPin to the containerPortConfigSet 0DioOpen and Explorer the container “Dio” Go to the container “Dio Port 0” and add a port with the following proprieties: Name: Dio PG DioPortId: 6Add a DioChannel to the Container “Dio PG” Name: Led2 PortPinPcr 99 Name: Dio Led2 PortPinDirection PortPinDirectionOut DioChannelId: 6 TMExternal Use62#FTF2015
PORT Module Configuration Config VariantTMExternal Use63#FTF2015
PORT Module Configuration PortConfigSet and PortPinTMExternal Use64#FTF2015
PORT Module Configuration PortPin configurationTMExternal Use65#FTF2015
DIO Module Configuration Config VariantTMExternal Use66#FTF2015
DIO Module Configuration DioPort and DioPortIdTMExternal Use67#FTF2015
DIO Module Configuration DioChannel and DioChannel configurationTMExternal Use68#FTF2015
Code generation Objective: Generate configuration dataRight click on Training - select Generate ProjectNote: make sure that NO ERROR is reported to Error Log WindowTMExternal Use69#FTF2015
Code Compilation1. Open GreenHills Project fromDesktop/GHS Projects/Lab1.gpj2. Build the project by clicking on 13. Lauch the debugger applicationby clicking on 2TMExternal Use70#FTF201512
Debug and Run the Code Download the code by clicking on 1 and then Connect to the target Select GHS Probe (USB) (PowerPC 5748G (z4204), Id 0), then press Ok Run the code by clicking on 212 Result: LED2 start blinking with a 1 sec periodTMExternal Use71#FTF2015
AUTOSAR RunTime Application FlowECU StartupBefore AUTOSAR OSAUTOSAR InitializationECU RuntimeECUShutdownAUTOSAR tionAUTOSARShutdownSafe State ensured via System DesignAUTOSARHW/SWInitializationµC Firmware HW-Reset Low-Level Init HW Initialization Driver Initialization SW InitializationAUTOSARSW-C Initialization Start of OS System Services Software ComponentsSW-Componentsin control ofFunctions SW-Deinit HW-DeinitNot AUTOSARAUTOSARTMExternal Use72#FTF2015
Lab2 Dimming LED Objective ImplementingADC reads and PWM changes with AUTOSAR MCALin context of AUTOSAR OS Get familiar with AutoSAR OS Environment AutoSARMCAL and AutoSAR OS v4.0 Tool: Elektrobit tresos Studio 2014.2.1 Compiler: GreenHills for PPC Debugger: GreenHills Probes Hardware: MPC5748G Evaluation Board Functional description TheAutoSAR BSW modules Mcu,Dio, Port, Adc, Pwm Os, EcuM, RTEare applied to build an application which toggles one LED every secondand dimms another LEDTMExternal Use73#FTF2015
ADC Driver: Functional Overview Adc Channel represents a ADC entity bound to one port pin NO own RAM bufferAdc Channel Group Agroup of Adc Channels linked to the same hardware unit Only groups can be triggered for conversion Adc driver module internally implements a state machine for each group Conversion Modes OneShot: the conversion of an ADC channel group is performed onceafter a trigger (software or hardware) and the result is written to theassigned buffer Continous: the conversions is repeated for each ADC channel in anADC channel groupTMExternal Use74#FTF2015
ADC Driver — Channel Group State MachineOne Shot / Software Trigger / Single AccessTMExternal Use75#FTF2015
PWM Driver: Functional Overview Each PWM channel corresponds to ahardware PWM on the device Polarity A parameter PwmPolarity specifies the pin outputlevel for each channel for dutycycle and offdutycycle.PWM duty cycle scaling resolution: 16bit range: 0x0000 (0%) to 0x8000 (100%) PWM Time Unit TMExternal Use76#FTF2015Timing is adressed by Mcu. Pwm expects all timevalues expressed in ticks.Type of PWM channel is implementationspecific (e.g. center align, left align, .)
LAB2: Dimming LED1.2.3.4.5.6.Opening a Tresos ProjectExprore PWM and ADC parametersCreate
TM External Use 6 #FTF2015 AUTOSAR Vision Hardware and software will be widely independent of each other Development can be de-coupled by horizontal layers. This reduces development time and costs The reuse of software increases at OEM as well as at suppliers. This enhances quality and efficiency AUTOSAR aims to standardize the software architecture of ECUs.
AUTOSAR 3.x AUTOSAR 4.x AUTOSAR 3.x is used in serial production projects by: Audi / Volkswagen / Porsche Daimler Fiat / Chrysler Volvo Trucks (incl. Construction Machines) AUTOSAR 4.x is used in serial production projects by: BMW GM Toyota Volvo Cars AUTOSAR 4.x is generally announced by Ford PSA
Simon Fürst, BMW Group Safetronic 2011 8 Nov. 2011, Sheraton Arabellapark Hotel, Munich. 2 8 Nov. 2011 AUTOSAR and Functional Safety . Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
AUTOSAR User Group, i.e. the Artop User Group . –It is a group of AUTOSAR members and partners, i.e. users of AUTOSAR, with a special interest in AUTOSAR tools. –Was launched in October 2008 and the members currently are: –Continental –Geensys –Peugeot Citroën (PSA)–BMW Car IT –New members are welcome to join the User Group.
Both, Releases 2.0 and 2.1, are in use by several AUTOSAR members for series produc-tions. 2.2. Overview on AUTOSAR Phase II Three releases had been planned for AUTOSAR Phase II, providing a continuous improve-ment of the specifications and introducing new concepts. Release 3.0 was published early 2008 on the AUTOSAR web site [1]. It included a .
2 Introduction to AUTOSAR Simulink approach to AUTOSAR Overview of Modeling SWCs & Modeling Styles AUTOSAR Design Workflows Bottom Up, Top Down & Round Trip Advanced Topics –Top 5 Startup, Reset, and Shutdown Modeling Basic Software (BSW) Access J-MAAB Type B Architectu
Adaptive Environment - The AUTOSAR Adaptive environment for adaptive design AUTOSAR Builder is based on Eclipse and uses Artop. Artop is an open AUTOSAR tool environment that is available for free. It enables you to build your own tools and integrate from other tool vendors. For more details, see the AUTOSAR Builder Overview document. 1.
Configuration Management Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 888 Document Status published Part of AUTOSAR Standard Adaptive Platform Part of Standard Release R20-11 Document Change History Date Release Changed by Description 2020-11-30 R20-11 AUTOSAR Release Management Classic Plaftorm update .
AUTOSAR Methodology at BMW Page 2. OVERVIEW. AUTOSAR Versions and Roadmap Configuration Process until Generation 2015 Vision Generation 2021 and Current Status Generation 2018 Tool Architecture Tool Development ECU Configuration Flow AUTOSAR Tool Requirements for the Future
