Transcription
Application Interfaces User GuideAUTOSAR CP Release 4.3.1Document TitleApplication Interfaces UserGuideDocument OwnerDocument ResponsibilityDocument Identification NoAUTOSARAUTOSAR442Document StatusPart of AUTOSAR StandardPart of Standard ReleaseFinalClassic Platform4.3.1Document Change HistoryDateRelease Changed seManagementAUTOSARAdministrationChange Description Editorial changes Add chapter about implementationof data types as integer or floatingpoint data types – Chapter ID4.2.3.3. Bugzilla # 72021 Updated explanation of theCOMPU METHOD reusage Updated the Linear ConversionExample Sensors and Actuators Patternadopted in the AI Domain Obsolete AI Table substituted bynew official AI Tool for contentdevelopment phase and arxmlgeneration Enhanced collections arxmldeliverables structure New ARXML file distribution feature Updated categories of modelelements (Data Constraints andKeywords to Blueprints) Introduced description of BackwardCompatibility, Lifecyle State andVariant Handling (Views) concepts Deliverables from ApplicationInterfaces updated1 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1Document Change HistoryDateRelease Changed 0.2AUTOSARAdministrationChange Description Description of Categories of modelelements created Synchronization of Update of XMLpackage structure especiallyregarding Port Blueprints Synchronization to updates ofAUTOSAR meta model Description of Naming conventionsfor connectors Initial Release2 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1DisclaimerThis work (specification and/or software implementation) and the material containedin it, as released by AUTOSAR, is for the purpose of information only. AUTOSARand the companies that have contributed to it shall not be liable for any use of thework.The material contained in this work is protected by copyright and other types ofintellectual property rights. The commercial exploitation of the material contained inthis work requires a license to such intellectual property rights.This work may be utilized or reproduced without any modification, in any form or byany means, for informational purposes only. For any other purpose, no part of thework may be utilized or reproduced, in any form or by any means, without permissionin writing from the publisher.The work has been developed for automotive applications only. It has neither beendeveloped, nor tested for non-automotive applications.The word AUTOSAR and the AUTOSAR logo are registered trademarks.3 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1Table of Contents1Purpose of this document . 71.12Document Overview . 7Introduction to Application Interfaces Table . 82.13Structural overview of Domains in AI Table . 10AUTOSAR Methodology . 113.1Overview on available documents . 123.1.1Software Component Template [1] . 123.1.2Standardization Template [2] . 123.1.3Generic Structure Template [4] . 123.1.4AI Specification [6] . 123.1.5Modeling Guide for Application Interfaces [9]. 123.1.6AUTOSAR Methodology [10] . 123.1.7Explanation of Application Interfaces for Domain Body Comfort [11] . 133.1.8Explanation of Application Interfaces for Domain Powertrain [12] . 133.1.9Explanation of Application Interfaces for Domain Chassis [13] . 133.1.10 Explanation of Application Interfaces for Domain Occupant andPedestrian Safety [14] . 133.1.11 Explanation of Application Interfaces for Domain Multimedia,Telematics, Human Machine Interface [15] . 134Metamodel representation of AI Table . 144.1Category of Model Elements . 144.1.1STANDARD . 144.1.2BLUEPRINT . 144.1.3 EXAMPLE . 154.2Meta model diagrams and the AI Table . 154.2.1Composition . 154.2.2Blueprint Mapping & BlueprintMappingSet. 204.2.3PortPrototypes . 214.2.4PortInterfaces. 234.2.5DataTypes. 264.2.6Physical Units . 324.2.7Computation Methods . 334.2.8Keyword and KeywordSet . 335Backward Compatibility . 364 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.15.15.25.36Introduction. 36Backward Compatibility Definition . 36Summary . 39Life Cycle States . 406.16.26.37Introduction. 40Representation in AI Table . 40Representation in meta model and arxml . 41View Concept in Application Interfaces (Variant Handling) . 437.17.28Introduction. 43Implementation in Application Interfaces and Meta Model Representation 43Structure of Application Interfaces (AI) Table . 478.1Main sheets of the AI Table . 478.1.1Sheet 04 Keywords . 478.1.2Sheet 05 TopLevel . 488.1.3Sheets 050xxxxx . 518.1.4Sheet 06 Interfaces DataElements (SenderReceiverInterface) . 528.1.5Sheet 06 Interface ClientServer . 548.1.6Sheet 07 DataTypes ContinuousValue . 568.1.7Sheet 08 DataTypes Enumeration . 568.1.8Sheet 09 DataTypes Array . 588.1.9Sheet 11 DataTypes Record . 598.1.10 Sheet 13 Units . 618.1.11 Sheet 15 Redirected Ports . 628.2Complete List of all Sheets of the AI Table . 639Relationship between AI Table data and XML Output . 669.1Overview . 669.1.1Dependencies of XML Generation . 669.1.2Contents of Generated XML . 669.1.3 Schema Structure . 689.2Common Elements . 709.2.1Package Structure . 709.2.2References. 759.2.3Instance References . 759.2.4Type References. 769.2.5 Descriptions . 769.3Component Types . 779.3.1Composition Types . 789.3.2Ports. 795 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.19.3.3Components. 799.3.4 Connectors. 809.4PortPrototypeBlueprints . 829.5PortInterfaces . 839.5.1Sender-Receiver-Interface . 839.5.2 Client-Server-Interface . 849.6Blueprint Mapping Sets . 869.7Data Types . 879.7.1Continuous Value Types . 879.7.2Enumeration Types . 919.7.3Array Types. 939.7.4Record Types. 949.7.5 Float Types . 959.8Units . 959.9Life Cycle State . 969.10 Views . 9910References . 10110.110.2Standard documents . 101Auxiliary documents . 1016 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.11Purpose of this documentAUTOSAR aims at the delivery of functionality through communicating SoftwareComponents, which can be placed nearly arbitrarily on a network of ECUs. To ensurethe interoperability of Software-Components from different sources (i.e. vendors), theinterfaces of these should be unified.The content of the AI Table [8] is the specification of interfaces of several automotivedomains. The composition of these domains will establish the Top-level domaininside the table. The goal is to define and publish stable and widely acceptedapplication interfaces.This document aims at explaining all relevant details about the AI Table especially forusers, who have to maintain the standardized application interfaces. Experiencedusers can skip the chapter AUTOSAR Methodology. Some sections contain extractfrom other AUTOSAR documents. In case of differences in the contents then theoriginal AUTOSAR documents are valid.1.1 Document OverviewThis document gives an overview of the methodological background of theapplication interfaces. This document also gives an overview of the content of the‘Application Interface Table’, the top level (inter-domain level) and included domains(Body, Powertrain, Chassis, Occupant and Pedestrian Safety, Multimedia,Telematics, Human Machine Interface). It also describes the structure of the AI Table(realized in an Excel table) and explains how to handle it.Abbreviations ListAbbreviation.arxmlAI WPXMLXSDHMIMeaningAutosar Extensible Markup Language FileApplication Interface TableTool for change request managementCentral Processing UnitElectronic Control UnitMicrosoft spreadsheet-applicationMilestoneRun-Time EnvironmentSoftware Process Engineering meta-modelSubversion (version control isual BasicVirtual Function BusWork packageExtensible Markup LanguageXML Schema DefinitionHuman Machine Interface7 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.12Introduction to Application Interfaces TableThe application interface table (AI Table) is the user interface dedicated to manageall the data, which define the application interfaces (see Figure 1). This isimplemented in a tool (Excel) with validation and work product output generationmacros (e.g. VB scripts). Input to the tool is based on AUTOSAR definedmethodology meta-model data. The output of the tool is a XML model, which isconform to the XSD and follows the semantics defined in the template. TheAUTOSAR XML file (called .ARXML file) contains detailed information in a structuredformat of all the standardized application interfaces data. The xml file contains thedefinitions of the application interfaces transferred to a commonly readable format,which can be the input for e.g. authoring tools at the development units of SWdeveloping companies.Figure 1: The AI Table ProcessThe AI Table enables the manipulation of AI definitions in order to produce theoutcome: the xml file for data exchange.The SWC template [1] tells us what can be modeled. The Standardization Template[2] explains and supports the blueprint approach.The AI Table description (i.e. XML) tells us what is being modeled. The AI Tabledefinitions follow the modeling guide defined by SWC modeling guide [9]. Thefollowing Figure 2 shows the main structure of SW composition and theirdecomposition into components.In order to standardize application interfaces a number of SW components aredescribed within the AI Table decomposed to the domains and their main functions.Nevertheless, these components must be seen as examples only (at present forRelease 4.0 only). They are not part of the standard; but they are necessary in orderto specify the port / port prototypes in a consistent way. Each port / port prototypeneeds a connection to a component to be specified in a proper way.8 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1The structure within Figure 2 illustrates the decomposition of Software-Compositionsusing the AUTOSAR Software Component Template [1].Figure 2: Decomposition of a component using the concepts defined in the softwarecomponent templateNote: The yellow blocks in the figure represent the AI Table columns with yellowcolor, which are the composition that is decomposed into other compositions /components. These component types and prototypes are described within the sameAI Table sheet in blue colored columns (see blue blocks in the figure). ASwComponentPrototype implements the usage of a SwComponentType in a specificrole.SwComponentPrototypes are only used for implementing SwComponentTypes in aspecific role, i.e. they are used to instantiate the SwComponentType.Example: a SwComponentPrototype ”LeftDoorControl” fulfills the role ofimplementing the SwComponentType ”DoorControl” for the left door of a vehiclewhile the SwComponentPrototype ”RightDoorControl” fulfills the role of theSwComponentType ”DoorControl” for the right door.The AI Table is an Excel table containing a number of work sheets. Within the sheetsthe following main information that are application interface relevant are handled: Compositions; main compositions are from domains (1) Body, (2) Powertrain, (3)Chassis, (4) Occupant and Pedestrian Safety, (5) multimedia and telematics andhuman machine interface Components Ports PortInterfaces and its VariableDataPrototypes Data types for VariableDataPrototypes Units Instances of component types9 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1 KeywordsFor a detailed list of sheets provided by the table, refer to Chapter 8.2.1 Structural overview of Domains in AI TableCurrently the AI Table contains the specification of a number ofdomains. The outcome of each domain including inter-domainidentified within the sheets of the AI Table: Interdomain level (Top level) Body Powertrain Chassis Occupant and pedestrian safety Multimedia, Telematics, Human Machine Interface (HMI)different automotiveconnections can beSheet: 0500Sheet: 0501*Sheet: 0502*Sheet: 0503*Sheet: 0504*Sheet: 0505*Although the table is structured following the domains, the resulting decompositioninto components/compositions is not a mandatory architecture for AUTOSARcompliant vehicle architectures. The AI Table shows components/compositions asexamples for explanation of standardized ports and PortInterfaces. The top levelcomposition is a dummy composition required to represent the inter domain ports inthe VFB view.Further explanations on domain details can be found in chapter 3.1.7 to 3.1.11 andfurther referenced documents.10 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.13AUTOSAR MethodologyAUTOSAR requires a formal technical approach for some steps of systemdevelopment. This approach is called the “AUTOSAR Methodology”. The AUTOSARMethodology is neither a complete process description nor a business model and“roles” and “responsibilities” are not defined in this methodology. Furthermore, it doesnot prescribe a precise order in which activities should be carried out. Themethodology is a mere work-product flow: it defines the dependencies of activities onwork-products.During system design, the software components and the hardware have to beselected, and overall system constraints have to be identified. AUTOSAR intends toease the formal description of these initial system design decisions via theinformation exchange format and the use of templates. So defining the SystemConfiguration Input means to fill out or edit the appropriate templates. AUTOSARmethodology allows for a high degree of reuse in this context. In any case, thisediting is assumed to be supported by editing tools. Here is a brief description ofactivities:Figure 3: Overview AUTOSAR Methodology- Configure System: mainly maps the software components to the ECUs with regardto resources and timing requirements.The SW-component description, system constraints description and ECU resourcesdescription are required to configure the system.The AI Table output along the internal behavior defines the SW-componentdescription.The output of this activity is the System Configuration Description. This descriptionincludes all system information (e.g. bus mapping, topology) and the mapping ofwhich software component is located on which ECU.- Extract ECU-Specific Information: extracts the information from the SystemConfiguration Description needed for a specific ECU. This is then placed in the ECUExtract of System Configuration.- Configure ECU: adds all necessary information for implementation like taskscheduling, necessary Basic Software modules, configuration of the Basic Software,assignment of runnable entities to tasks, etc. The result of the activity Configure ECU11 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1is included in the ECU Configuration Description, which collects all information that islocal to a specific ECU. The runnable software to this specific ECU can be built fromthis information.- Generate Executable: an executable is generated based on the configuration ofthe ECU described in the ECU Configuration Description. This step typically involvesgenerating code (e.g. for the RTE and the Basic Software), compiling code(compiling generated code or compiling software-components available as sourcecode) and linking everything together into an executable.Nevertheless, the implementation of a software component is more or lessindependent from ECU configuration.The general concepts of this chapter are an extract of the detailed AUTOSARMethodology [10].3.1 Overview on available documentsFor detailed information, following documents are available.3.1.1 Software Component Template [1]This document provides introductory description and rationale for the part of theAUTOSAR meta-model relevant for the definition of Software Components.3.1.2 Standardization Template [2]This document is intended to support the delivery of standardized model elements byAUTOSAR. This document also refines the blueprint approach for standardization.3.1.3 Generic Structure Template [4]This document acts as a supplement for the formal definition provided by theAUTOSAR meta model. This document provides the introductory description andrationale for the parts of the AUTOSAR meta model relevant for all AUTOSARtemplates.3.1.4 AI Specification [6]This is the output of the standardization of Application Interfaces. The output isdelivered as a set of .arxml files.3.1.5 Modeling Guide for Application Interfaces [9]This document gives guidelines and conventions on using the AUTOSAR modelelements in order to build AUTOSAR systems. It does not contain guidelines for theAUTOSAR meta-model.3.1.6 AUTOSAR Methodology [10]See above.12 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.13.1.7 Explanation of Application Interfaces for Domain Body Comfort [11]The document explains design decisions and boundary conditions that lead to theApplication Interfaces of the domain Body and Comfort.3.1.8 Explanation of Application Interfaces for Domain Powertrain [12]The document explains design decisions and boundary conditions that lead to theApplication Interfaces of the domain Powertrain.3.1.9 Explanation of Application Interfaces for Domain Chassis [13]The document explains design decisions and boundary conditions that lead to theApplication Interfaces of the domain Chassis.3.1.10 Explanation of Application Interfaces for Domain Occupant andPedestrian Safety [14]The document explains design decisions and boundary conditions that lead to theApplication Interfaces of the domain Occupant and pedestrian safety.3.1.11 Explanation of Application Interfaces for Domain Multimedia, Telematics,Human Machine Interface [15]The document explains design decisions and boundary conditions that lead to theApplication Interfaces of the domain Multimedia, Telematics, Human MachineInterface.To find these documents refer to the table at the end of this document (See Chapter10).13 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.14Metamodel representation of AI TableThis section describes the relation between meta-model implementation (AUTOSARMeta Model [7]) and representation within the AI Table [8]).The AUTOSAR meta-model conceptually is defined as ‘M2’ level, which describesthe entities called software components and ports. The relations between thoseentities as well as their semantics are part of this model.4.1 Category of Model ElementsAll Application Interface model elements are classified into three different categories.They are;STANDARDBLUEPRINTEXAMPLE4.1.1 STANDARDAll elements, which can be used as they are defined by just including them in theproject, belong to the category STANDARD. These elements need no modificationsbefore their use in the projects.Elements of category STANDARD are; PhysicalDimensions Units LifeCycleInfoSets4.1.2 BLUEPRINTBlueprints are the pre-definition of model elements, which form the basis for furthermodeling. Blueprints are model elements from which other model elements can bederived by copying. These elements are not complete in all aspects. They act as atemplate for projects to create the real elements.Elements of category BLUEPRINT are; ApplicationDataTypes CompuMethods DataConstraints KeywordSets PortInterfaces PortPrototypeBlueprints CollectionsRules for naming Prototypes derived from BLUEPRINTsAUTOSAR Standardization will use rules for creating ShortNames for prototypesderived from blueprints, i.e. the recommendation below is mandatory for AUTOSARstandardization work. Recommendation in case of single usage: ShortName Recommendation in case of multiple usage: ShortName { Keyword }0.n"14 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1 The ShortName pattern for the derived model elements may follow a{anyName} pattern from the associated Blueprints4.1.3 EXAMPLEElements that shall not be standardized, but are helpful for understanding arecreated as category EXAMPLE. These act as help for the users to actually createtheir project specific implementations. The elements of category EXAMPLE representone out of many possible ways of implementation.Elements of category EXAMPLE are; SwComponentTypes ApplicationDataTypes BlueprintMappingSets CompuMethods DataConstrs PortInterfacesApplicationDataTypes, CompuMethods, DataConstrs and PortInterfaces categorizedas examples are the derived elements from their blueprints and are not additionalelements.4.2 Meta model diagrams and the AI TableThis section describes the AUTOSAR meta-model (M2) diagrams and theirrelationship with the AI Table contents to implement the application softwarecomponent.The following diagrams correspond to R4.0 of the AUTOSAR meta-model.4.2.1 CompositionFigure 4: Composition15 of 101Document ID 442: AUTOSAR EXP AIUserGuide- AUTOSAR confidential -
Application Interfaces User GuideAUTOSAR CP Release 4.3.1The purpose of an AUTOSAR CompositionSwComponentType is to allow theencapsulation of specific functionality by aggregating existing software-components.Since a CompositionSwComponentType is also a SwComponentType, it may beaggregated again in further CompositionSwComponentTypes. This recursive relationis formally expressed in Figure 4.It is important to understand that while compositions allow for (sub-) systemabstraction, they are solely an architectural element for the implementation of modelscalability. They simply group existing software-components and thereby take awaycomplexity when viewing or designing logical system architecture.Meta Model e::Composition [1]AI Table Reference:AUTOSAR ApplicationInterfaces.xls [8]Work Sheet Name: CompositionsFigure 5: part of sheet ‘Compositions’Example:In the case of Exterior light Composition found in sheet 050106 ExteriorLight: the“ExtrLi”which is a CompositionSwComponent type, composed of prAut,AdprCornrg,AdprHomeCmngAndHomeLvng, HdlampLvlMgr, ActrOfHdlampLvlg etc AI Table Reference:AUTOSAR ApplicationInterfaces.xls [8]Work Sheet Name: InstancesFigure 6: part of sheet ‘Instances’Example: The component type ExtrLiMgr is not decomposed further into componenttypes therefore; it is just a component type. The component prototype ExtrLiMgrfound in 050106 ExteriorLight (cell AB2 shown in Figure 7) is of the type ExtrLiMgr(component type). Here the type and prototype have the same ShortName.The component prototypes ActrOfHdlampLvlgLe and ActrOfHdlampLvlgRi found in050106 Exte
implemented in a tool (Excel) with validation and work product output generation macros (e.g. VB scripts). Input to the tool is based on AUTOSAR defined methodology meta-model data. The output of the tool is a XML model, which is conform to the XSD and follows the semantics defined in the template. The
