3 Autosar Axelsson

10m ago
867.32 KB
14 Pages
Last View : 1m ago
Last Download : 3m ago
Upload by : Joanna Keil

AutoSAR OverviewFESA Workshop at KTH 2010‐04‐12Prof. Jakob AxelssonVolvo Cars andMälardalen UniversityThis presentation is based on a tutorial prepared by theAutoSAR Consortium

AUTOSAR – MembersStatus June 200710 Core Partners49 Premium Members57 Associate Members2

Exchangeability and Reuse of SW ComponentsOEM bExchangeabilitybetween supplier‘ssupplier ssolutionsOEM aOEM cPlatform b.1Platform b.2Platform b.nPlatform a.1Platform a.2Platform onsSupplier A¾ Chassis¾ Safety¾ Body/Comfort¾ MultimediaSupplier B¾ Chassis¾ Safety¾ Telematics¾ MultimediaSupplier C¾ Body/Comfort¾ Powertrain¾ TelematicsT lti¾ MultimediaOEM fOEM ePlatform c.1Platform c.2Platform c.nOEM dPlatform d.1Platform d.2Platform d.nExchangeabilityPlatform f.1Platform f.2Platform f.nPlatform e.1Platform e.2Platform e.nbetween vehicleplatforms3

Changing Automotive SW DevelopmentConventionalSoftwareAUTOSARApplication rdware Hardware and software will be widely independent of each other.pprocessespwill be simplified.p DevelopmentThis reduces development time and costs. Reuse of software increases at OEM as well as at suppliers.This enhances also quality and efficiency.Automotive Software will become a product.

AUTOSAR Main Working ectureApplicationMethodologyInterfaces¾ Architecture:Software architecture includingg a completepbasic or environmentalsoftware stack for ECUs – the so called AUTOSAR Basic Software – asan integration platform for hardware independent softwareapplications.¾ Methodology:Exchange formats or description templates to enable a seamlessconfiguration process of the basic software stack and theiintegrationi off applicationli i softwarefini ECUs andd iti includesi l d even thehmethodology how to use this framework.¾ Application Interfaces:Specification of interfaces of typical automotive applications fromall domains in terms of syntax and semantics, which should serve asa standard for application software.5

Intra‐ and Inter‐ECU CommunicationPorts implement the interface according tothe communication paradigm (here client‐server based).ECU IPorts are the interactionpoints of a component.Appli‐cationSW‐CThe communication isAchanneled via the RTE.The communication layerin the basic software isencapsulated and notRTEvisible at the applicationllayer. BSWECU wareCommunication BusCommunication Path6

AUTOSAR MethodologyVFB viewSW‐CDescriptionSW‐CSW‐CSW‐CDescription Description C2AUTOSARSW‐C1.StandardizedStd di d ddescriptioni ti ttemplatesl t fforapplication software components(interfaces and BSW requirements)Virtual Functional BusECUDescriptionsSystem ConstraintDescriptionStandardized exchange formats andmethodology for component, ECU,and system levelTool supporting deploymentof SW componentsMappingECU IECU IIECU sicSoftwareTools for‐ support of component mapping‐ generation of RTE, i.e. inter‐ andintra ECU communicationStandardized Basic Software (BSW)architecture, detailed specificationsfor implementation and configurationof BSWGateway7

AutoSAR DescriptionsECUsSoftware ComponentsSwitchEvalSW‐Component DescriptionECU ResourceDescriptionECU ResourceDescriptionECU Component DescriptionBlinkInputModuleSSupportedt d protocols:t lCAN, LIN, ent asterLightActuatorsControlCANLINSW‐Component LLM‐RSW‐Component Description8

AUTOSAR System Design ProcessInput: Requirements & Vehicle Info1a1cSW ComponentDescriptionSystemDDescriptioni ti1bECU ResourceDescription2Configure System& generate extractsof ECU descriptions3Iterative correctionsand/or optimizations(if required)Configuregeach ECUSW Component4Generate SWexecutablest blfor each ECUSW executablesfor each ECU9

AUTOSAR System Design ProcessInput: Requirements & Vehicle Info1a1cSW ComponentDescriptionSystemDescription1bECU ResourceDescription2Configure System& generate extractsof ECU descriptionsSW Component Description General characteristics (name, manufacturer, etc.) Communication properties:‐ p ports‐ r ports‐ interfacesSW Componentinner structure (composition)‐ sub‐components‐ connections required HW resources:‐ processing time‐ scheduling‐ memory (size, type, etc.)3Iterative correctionsand(/or optimizations(if required)Configureeach ECU4Generate SWexecutablesfor each ECUSW executablesfor each ECU10

AUTOSAR System Design ProcessInput: Requirements & Vehicle Info1a1cSW ComponentDescriptionSystemDescription1bECU ResourceDescription23Configure System& generate extractsIterative correctionsof ECU descriptionsECU Resource Descriptionand(/or optimizations General characteristics (name, manufacturer, etc.)(if required) Temperature (own, environment, cooling/heating)Configureeach ECU Available signal processing methods Available programming capabilitiesSW Component4 Available HW:Generate SWexecutablesfor each ECU‐ µC, architecture (e.g. multiprocessor)‐ memory‐ interfaces (CAN, LIN, MOST, FlexRay)‐ periphery (sensor / actuator)‐ connectors (i.e. number of pins) SW below RTE for micro controller Signal path from Pin to ECU‐abstractionSW executablesfor each ECU11

AUTOSAR System Design ProcessInput: Requirements & Vehicle Info1a1cSW ComponentDescriptionSystemDescription1bECU ResourceDescription2Configure System&generateextractsSystemDescriptionof ECU descriptions Network topology‐ bus systems: CAN, LIN, FlexRay3 ‐ connected ECUs, Gateways‐ powersupply, system activationConfigureSW ComponentIterative correctionsand(/or optimizations(if required) Communication (foreacheachECUchannel)‐ K‐matrix‐ gateway table4Generate Mapping / Clusteringof SW SWcomponentsexecutablesfor each ECUSW executablesfor each ECU12

AUTOSAR Metamodel The metamodel is modeledin UML The structure of theinformation can be clearlyvisualized The consistency of theinformation is guaranteed Using XML, a data exchangeformat can be generatedautomatically out of erfaceMODELMirrorAdjustmentMirrorActuator

Application Interfaces to Ease ReuseData Type NameLongAccBase ESP-SensorsESP-SensorsBase Sensor SignalsData Type NameYawRateBaseDescriptionYaw rate measured along vehicle z- axis(i.e. compensated for orientation).Coordinate system according to ISO8855Data TypeS16Integer Range-32768. 32767Physical Range-2,8595. 2,8594Ph i l OffsetPhysicalOff t0Unitrad/sec .RemarksThis data element can also be used toinstantiate a redundant sensor interface.Range might have to be extended forfuture applications (passive safety).I1Interface of ESPand VLCÍnterface of ESP andexternal yaw ratecontroller2nd2nd ponentSW-ComponentSystem-level BrakeActuator trollerControllerStandard Signalsfrom ESPI2I3Information signalsgfrom other functions /domainsCommand signals toother functions /domainsI7I5BrakeBrake ActuatorActuatorStandardized application interfaces onsystem level(ESP‐system, chassis domain) Data Type NameRollRateBase14

Conventional AUTOSAR Software Application Software AUTOSAR standardized Hardware Hardware HW‐specific Hardware and software will be widely independent of each other. Development processes will be simplified. This reduces development time and costs. Reuse of software increases at OEM as well as at suppliers.

Related Documents:

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 .

Abstract- Abrasive Water Jet Machining (AWJM) is a versatile machining process primarily used to machine hard and difficult to machine materials. The objective of this paper is to optimize material removal rate and kerf width simultaneously using AWJM process on INCONEL 718. The process parameters are chosen as abrasive flow rate, pressure, and standoff distance. Taguchi Grey Relational .