Systematic Use Of The AUTOSAR Standardized Application .
Systematic Use of the AUTOSAR StandardizedApplication InterfacesA Ozhigin, M Golm, S VogetTo cite this version:A Ozhigin, M Golm, S Voget. Systematic Use of the AUTOSAR Standardized Application Interfaces.Embedded Real Time Software and Systems (ERTS2008), Jan 2008, Toulouse, France. insu-02269700 HAL Id: /insu-02269700Submitted on 23 Aug 2019HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.
Systematic Use of the AUTOSAR Standardized ApplicationInterfacesA. Ozhigin1, M. Golm2, S. Voget31: OOO Siemens, St. Petersburg, Russia2: Siemens Corporate Research, Princeton, USA3: Continental Corporation, Regensburg, e (AUTOSAR) initiative develops anopen standardized software architecture forautomotive electronics. The partnership is focusedon managing the growing complexity in thedevelopment of automotive electric/electronicarchitectures, with the aim of enabling newtechnologies and improving development efficiency –without making compromises on quality andlimitation of corporate tion on three pillars. First, a layeredarchitecture for electronic control units (ECU) isdefined and the lower layers, the basic software(BSW), is standardized on module level. Second, amethodology enables the configuration of systemswithin a collaboration process between OEMs andsuppliers. Third, on the highest architectural layer,SW-components and their application interfaces arestandardized.Especially in this third pillar, the standard does notstructure the SW-components with respect tofunctional vehicle models, neither for existing nor forfuture ones. Therefore, the link between thefunctional view on a vehicle and the SW architectureis still missing.This paper presents the standardized applicationinterfaces as part of the SW-architectures in usualvehicles. We embed the interfaces into a newframework that serves as a link between these SWarchitectures and functional vehicle models. As thefunctional models are normally OEM specific anddiffer from each other, the framework can be seen asthe necessary glue to realize different vehicles withthe help of the AUTOSAR standardized components.The concept will be validated with the help of afunctional model developed by Siemens VDOAutomotive AG. This functional model serves as avalidation of the framework. One main advantage ofthis framework is, that it enables the simulation ofthe behaviour of the components, i.e. the ECUs, onvehicle level.The increasing total share of software in the field ofautomotive systems resulted in high complexity andhigh costs. This became more critical with nonstandardized development processes and withoutadequate networks. In addition, the incorporation ofthird party software increased the complexity ofcollaboration between companies.An appropriate level of abstraction in the vehiclesoftware architecture modeling and appropriateintegration concepts were still missing. Architecturesdid not reflect the effects of quality requirements. Asa consequence these often remained vague andunexplored. The architectures grown up by thesingle solution development strategy did notrepresent long-term solutions.In modern vehicles the realization of a lot offunctionality is distributed among several ECUs. E.g.the software, that controls the lights of the indicatorfunctionality, is distributed over up to eight ECUs inhigh end vehicles. Furthermore, some of the futurefunctionality is not realizable with a loose set of sideby side ECUs. E.g. drive-by-wire will need a veryclose and safe interlocking of ECUs across differentdomains. The traditional split of automotive functionsis more and more crossed by the upcomingfunctionalities.With respect to this background the leadingautomobile companies and their 1st Tier suppliersfounded a partnership in 2003, which establishes anindustry-wide standard for the ARchitecture) is leaded by 10 "Core Partners".These are BMW Group, Bosch, Continental,DaimlerChrysler, Ford Motor Company, GeneralMotors, PSA Peugeot Citroën, Siemens VDO,Toyota Motor Corporation and Volkswagen.AUTOSAR is set up as a partnership to define anindustry wide standard.Keywords: AUTOSAR, functional model, softwarearchitectureTo fulfill the requirements in the “MainRequirements” [1], the AUTOSAR consortiumdefined a new development methodology forautomotive software and software architecture. The1. Introduction2. The AUTOSAR conceptPage 1/8
development methodology is focused on a modeldriven development style. The software architecture,as well as the ECU hardware and the networktopology, are modeled in a formal way, which isdefined in a metamodel that supports the softwaredevelopment process from architecture up tointegration. All available modeling elements arespecified by the “AUTOSAR metamodel” [2]. Themetamodel is defined according to the rules of theOMG Meta Object Facility [5].According to AUTOSAR, software is composed ofAUTOSAR Software Components (SW-C) thatrepresent the application layer. During developmenttime these components communicate through aVirtual Functional Bus (VFB) principle. Duringruntime this VFB is implemented by a so calledRuntime Environment (RTE) which hides the lowerarchitectural layers, the Basic Software (BSW) [2],[3] from the applications, i.e. the SW-Cs. Thus,AUTOSAR Software Components encapsulate partsof application functionality and are independent ofthe infrastructure represented by RTE and BSW.AUTOSAR infrastructure capabilities make SW-Cindependent from the type of microcontroller, type ofECU, location of the other SW-Cs with which thecomponent interacts and the number of componentinstances. AUTOSAR Software Components arecapable of containing a set of logicallyinterconnected components. In such a case thecomponent is called a “composition”. In order ities across ECUs of different vehicleplatforms, besides all aspects of softwareinfrastructure, generic component concept anddevelopment methodology, AUTOSAR standardizesapplication software components and theirinterfaces.The envisioned development methodology starts bydefining the software architecture. An exemplarysoftware architecture can be seen in Figure 1.SoundSystemAmplifierLef.CDPlayerThe boxes represent the software components. Atthe perimeter of the boxes the communication portsof the software components are shown. A port withan inward pointing triangle is a so called RequiredPort. A port with an outward pointing triangle is aProvided Port. Required ports are the data receiversin a data flow-oriented communication, providedports are the senders. A provided port can beconnected with one or more required ports of othersoftware components. To be able to connect ports,the interfaces of the two ports must be compatible.There are two types of interfaces, s.Asender/receiver interface supports message-basedcommunication, while a client/server munication.A sender/receiver interface consists of a list of dataelements. Each data element has a name and a datatype.The client/server interface consists of a list ofoperations. Each operation has a signature,consisting of a name and a list of parameters. Eachparameter is described by a name, a type and adirection, which can be either in, out or in-out. Thedetails of all software component related modelingelements are described in the “Software ComponentTemplate Specification” [4].The software architecture is defined withoutconsideration of the hardware on which the softwarecomponents will run on later. This means that twosoftware components might run on the same ECU oron different ECUs. The communication between thecomponents is then either an intra-ECUcommunication or an inter-ECU communication. Toabstract from this difference, AUTOSAR introducesthe VFB. The VFB can be seen as a software bus towhich all components are attached.The hardware architecture is modeled in parallel tothe definition of the software architecture. AUTOSARallows for modeling the topology of a vehicle networkas well as the hardware of an ECU. An example ofthis topology can be seen in Figure ure 1: Example for software components andconnectorsESPFigure 2: Exemplary network topologyThe example shows two ECUs connected to apowertrain CAN network (PT-CAN) and one ECUPage 2/8
connected to a chassis CAN network (C-CAN). Thetwo CAN busses are connected through a gateway.Once the software architecture and the networktopology are defined, the software entities can bemapped to the hardware entities. The SoftwareComponent Template standardizes the format fordescribing the software entities and is a veryimportant part of the AUTOSAR metamodel. Itdefines how the software architecture is specified.3. Application InterfacesBesides the metamodel, which defines how anapplication interface is described, AUTOSARspecifies application interfaces as well. Standardizedapplication components are organized in ahierarchical way [8]. The top hierarchical levelconsists of the following functional domains: Powertrain; Chassis; Body; Safety; Multimedia, Telematics and HMI.Structures are elaborated for the first three domainsin phase 1 of AUTOSAR which ended in 2006The Body domain usually includes accesssubsystem, visibility subsystem, comfort subsystem,acoustic warnings etc. The Powertrain domaincoordinates torque producing, distributing andconsuming components (e.g. engine, transmission)in close interaction with the chassis domain, which inits turn is responsible for suspension, brakes, drivingdynamics and so on.Multimedia, telematics and HMI and safety domainswere not elaborated in phase 1.The top level decomposition into 5 domains is basedon a traditional structure of vehicle domaindecomposition rather than on flexible functionalvehicle model and thus couldn’t be considered asthe best way to represent software architecture.Compositions done by the traditional structuring aretending to represent rather currently availableproducts (such as ESP, ACC etc.) than generalizedview of software architecture. Such an approachdoes not contribute to future developmentprospective. Orientation on currently availableproducts can be considered as advantage in shortterm since it allows for easy adaptation of existingsoftware to be used in AUTOSAR-based systems.On the other hand, in long-term prospective suchapproach can aggravate the implementation of newfunctionalities and induce ambiguousness in theirreferring to standardized components thus causinginteroperability and portability problems.In further sections of this paper some functionalstructuring approaches will be considered. Theapplication of their principles towards the AUTOSARapplication software architecture serves as ameasure to elaborate the possibility to link theAUTOSAR application SW-Cs to a functional model.4. Overview of existing approachesIn the literature one can find several concepts tostructure the functionality of a vehicle into aconsistent model. In this section we present two ofthem.4.1. Module ConceptThe European funded project SPARC (SecurePropulsion Using Advanced Redundant Control) [10]dedicated to development of a safety decisioncontrol system for an accident-avoiding vehicleintroduced a module-oriented concept. Theydistinguish the following architectural layers [11]: Command layer - responsible for working out adesired motion vector derived from the driverinputs, supported by the human-machineinterface (HMI) and the advanced driverassistance systems (ADAS); Co-ordination layer - creates a secure motionvector for any driving situation by combining andarbitrating the inputs from the driver and theADAS; Execution layer - consists of the steering system,braking system, power pack and energy systemand maps the motion vector to physical reality bymeans of actuator control.Passenger Management functionalities are out ofscope of SPARC.The basic principle emphasized in SPARCarchitecture is separation of decision making(command or strategic) layer and layer to realizemade decision (execution layer) which are gluedtogether via co-ordination layer. One of the goals ofthe SPARC is to demonstrate the scalability (abilityto be used on the vehicle of different size) andtransferability (ability to be used on the vehicle lities ensured by the separation of threelayers.Such kind of layered structure provides the high levelof abstraction for the interface between the partresponsible for working out of ultimate decision onvehicle behavior in current situation and the partwhich performs the execution of the decision bymeans of control of actuators to the high abstractionlevel. This allows making command layer softwareentities independent of actual set and characteristicsof actuators and other means of control installed in aparticular vehicle and in that way facilitates theirreusability.This approach can be extended to encompass allvehicle systems [9]. In case of such extension thePage 3/8
vehicle architecture can be divided in 5 functionalmodules:1. User Interface2. Infrastructure3. Drivetrain/Chassis4. Passenger Management5. Driver AssistanceUser Interface module is responsible for allinformation interactions with driver and passengers:capturing input data (including driving-relatedintensions), transferring it to other modules, gettingfeedback information and presenting it to users.Driver Assistance module performs evaluation ofenvironment conditions basing on sensor data,generates current motion strategy and combines itwith driver intensions arriving from user interfacemodule by means of arbitration logic. The output isa motion vector to be implemented byDrivetrain/Chassismodule.Thismoduleencapsulates the means of execution of requiredmotion vector, stability functions based on reactiveenvironment evaluation and energy creation andmanagement. Passenger Management carries outall non-driver-specific tasks including infotainment,climate control, passive safety, windows, roof, doorlock control etc. All mentioned modules areinterconnected through an infrastructure modulewhich provides energy, power and signal distribution,means of communications with multiplexing andgateways, means of wireless connectivity.General modularization of the 5 module concept isshown in the Figure 3.Figure 3: Module DecompositionBasic criteria for the module decomposition looksimple and clear enough, but there could be sensorswhich are used together by driver assistance moduleand drivetrain/chassis module, this fact results inneed of widening of interface between thesemodules and blurs the boundary between them interms of assignment of components to a specificmodule.Whereas this structuring principle is based on theeffective implementation of the motion vector,different structuring principles exist in literature. Afurther one will be presented in the next chapter.4.2. CARTRONICCARTRONIC is proposed by Robert Bosch GmbHas an “open architecture for networking the controlsystems of an automobile” [7]. It introduces systems,components and communications as the elements ofthe architecture. System is considered as a set ofcomponents and communications that are integratedby function. Communications include orders,responses, requests and inquiries. Order is a directinstruction to the receiving component to performparticular action. Response with the reason is sentby receiving component if the order cannot befulfilled. Component can also inquire for necessaryinformation and request another component to dosomething.Possible communications between systems andcomponents are restricted with the followingstructuring rules [7]:1. A component can only get an order from onesingle source component (hierarchical flow oforders);2. Inquiries and requests are possible on the samelayer and upwards into higher layers.The first rule supports the avoidance of conflictsbetween different orders and clear allocation ofresponsibilities in the structure. It also implies thepresence of a coordinator component in eachsubsystem which dispatches orders to theembedded components. The second rule contributesto the component interchange and reuse.CARTRONIC distinguishes 3 types of componentsaccording to their functional roles: coordinators – perform resource management,conflict detection and resolution etc.; components with mainly operational tasks –execute orders, report resource requirement,provide resources etc.; information providers.CARTRONIC functional architecture is based on thefollowing principles: each system is made up of self-containedcomponents with a minimal number of physicalinterfaces; each system/component fulfills clearly definedtasks autonomously by obtaining information andinitiating orders; superordinated decision makers are used tocoordinate systems/components, they derive onesingle decision from the competing results; orders are propagated hierarchically from initiatorto actuator;Page 4/8
the interfaces of each system/component areknown to as many other systems/components asnecessary and as few as possible.On the high abstraction layer the structure of theentire vehicle consists of one vehicle coordinator,four components with operational tasks (control ofpower unit, control of vehicle motion, control of bodyand interior and control of electrical supply system)and four information providers (environment, traffic,vehicle and user), see Figure 4.and implementation of arbitration outcome by vehicledrivetrain. A framework to be applied to theAUTOSAR-based software architecture can becomposed as a combination of mentionedapproaches.The top level structure of the framework can beinherited from 5 Modules, first of all, the idea ofseparation of strategic layer responsible for makingdecisions on vehicle motion vector and executionlayer responsible for the implementation of themotion vector is to be adopted.Hierarchical rules of CARTRONIC can be used indefinition of internal structures of the modules. Dueto integration of all components controlling chassisand powertrain into a single Drivetrain module theoverhead caused by complexity and communicationconcentration in coordination components will bemitigated. Generalized view of the architectureframework combined from 5 module concept withCARTRONIC principles is shown in Figure 5(infrastructure module is not shown).Figure 4: CARTRONIC Vehicle ArchitectureAlthough CARTRONIC principles constitute aneffective way to manage vehicle electronic systemscomplexity their software implementation in thestraightforward way can encounter the followingdifficulties: high complexity of coordinators (mostly in powerunit, vehicle motion and vehicle coordinator dueto strong dependencies between power unit andvehicle motion), high communication overhead betweencoordinators and coordinators and mmunications in coordinator components canjeopardize the fulfillment of timing and memoryconsumption constraints.5. Combined framework for AUTOSAR softwarearchitectureThe major difference of architectural approachesdescribed above consists in the fact that ModuleConcept has an underlying use case as abackground when CARTRONIC is based ontraditional veh
AUTOSAR is set up as a partnership to define an industry wide standard. 2. The AUTOSAR concept To fulfill the requirements in the “Main Requirements” [1], the AUTOSAR consortium defined a new development methodology for automotive software and software architecture. The
May 02, 2018 · D. Program Evaluation ͟The organization has provided a description of the framework for how each program will be evaluated. The framework should include all the elements below: ͟The evaluation methods are cost-effective for the organization ͟Quantitative and qualitative data is being collected (at Basics tier, data collection must have begun)
Silat is a combative art of self-defense and survival rooted from Matay archipelago. It was traced at thé early of Langkasuka Kingdom (2nd century CE) till thé reign of Melaka (Malaysia) Sultanate era (13th century). Silat has now evolved to become part of social culture and tradition with thé appearance of a fine physical and spiritual .
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
On an exceptional basis, Member States may request UNESCO to provide thé candidates with access to thé platform so they can complète thé form by themselves. Thèse requests must be addressed to esd rize unesco. or by 15 A ril 2021 UNESCO will provide thé nomineewith accessto thé platform via their émail address.
̶The leading indicator of employee engagement is based on the quality of the relationship between employee and supervisor Empower your managers! ̶Help them understand the impact on the organization ̶Share important changes, plan options, tasks, and deadlines ̶Provide key messages and talking points ̶Prepare them to answer employee questions
Dr. Sunita Bharatwal** Dr. Pawan Garga*** Abstract Customer satisfaction is derived from thè functionalities and values, a product or Service can provide. The current study aims to segregate thè dimensions of ordine Service quality and gather insights on its impact on web shopping. The trends of purchases have
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 .
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
